Segmentation fault on an ARM device
#11
Hello derhass.

I have added the following line within what I took to be an appropriate place in my SConstruct file:
Code:
env.Append(CPPDEFINES = ['WORDS_NEED_ALIGNMENT'])
Recompiling with this modification in place makes no difference, though this may simply indicate an elementary error on my part.
Reply
#12
I dont recall having to use the alignment on the pandora which has a cortex A8. Ive encountered the alignment issue on older ARM's but nothing recent. But of course it could be because of a properly configured kernel.

One thing worth trying is if you  have /proc/cpu/alignment do:

Code:
echo 3 > /proc/cpu/alignment
Reply
#13
Hello Pickle.

Thank you for your suggestion. After running that command whilst logged in as root, and subsequently recompiling D1X in my usual way, executing a gdb backtrace now yields a new result:
Code:
#0  0x0001e15e in adjust_field_of_view ()
#1  0x00000000 in ?? ()

I do not know whether this is a significant change, but a SIGBUS error at the title screen nonetheless remains.

(I have a certain admiration for the Pandora community. It appears that Linux games have abounded on such a system, whilst there isn't quite the same zeal when it comes to my little stick.)
Reply
#14
what happens without running gdb, reason being echo 3 > /proc/cpu/alignment throws a signal and does the fixup. The signal I would expect halts gdb.
and for completeness here are the value possibilities:

0 - Do nothing (default behavior)
1 - Warning in kernel-log with PC and Memory-Address printed.
2 - Fixup error
3 - Warn and Fixup
4 - Send a SIGBUS to the process
5 - Send SIGBUS and output Warning
Reply
#15
Hello again.

Running the game without gdb results in the same problem; a generic segmentation fault is reported following the title screen crash. I am still unaware of whether I am adjusting the alignment value correctly, I must unfortunately add. The terminal gives me no confirmation of any change after I enter your command.

(I do apologise for the lateness of this reply. My filesystem became corrupted yesterday, prompting a fresh installation.)
Reply
#16
Hello once again.

On a whim, I attempted to see whether D2X would fare any better than D1X. Interestingly it did; the game loads successfully, and the visuals are impressively smooth. Unfortunately the game encounters a segmentation fault whenever an enemy robot appears on the screen. Such a crash produces this message:
Code:
0x0010f808 in g3_draw_tmap (nv=5, pointlist=0x2b9f54 <point_list>,
    uvl_list=0x106a8fa, light_rgb=0x17d9d30, bm=0xe73614 <GameBitmaps+352>)
    at arch/ogl/ogl.c:925
925            texcoord_array[index2]   = f2glf(uvl_list[c].u);
Similarly, a gdb backtrace gives the following long list of errors:
Code:
#0  0x0010f808 in g3_draw_tmap (nv=5, pointlist=0x2b9f54 <point_list>,
    uvl_list=0x106a8fa, light_rgb=0x17d9d30, bm=0xe73614 <GameBitmaps+352>)
    at arch/ogl/ogl.c:925
#1  0x0001587a in g3_draw_polygon_model (p=0x106a8d2 "\003",
    model_bitmaps=0xf62914 <texture_list>,
    anim_angles=0xe1fc9c <Objects+17560>, model_light=...,
    glow_values=0xbeffefb4) at 3d/interp.c:477
#2  0x00015942 in g3_draw_polygon_model (p=0x106a7f4 "\004",
    model_bitmaps=0xf62914 <texture_list>,
    anim_angles=0xe1fc9c <Objects+17560>, model_light=...,
    glow_values=0xbeffefb4) at 3d/interp.c:498
#3  0x000158e8 in g3_draw_polygon_model (p=0x1069ad0 "\004",
    model_bitmaps=0xf62914 <texture_list>,
    anim_angles=0xe1fc9c <Objects+17560>, model_light=...,
    glow_values=0xbeffefb4) at 3d/interp.c:492
#4  0x000dcce4 in draw_polygon_model (pos=0xe1fa96 <Objects+17042>,
    orient=0xe1faa2 <Objects+17054>, anim_angles=0xe1fc9c <Objects+17560>,
    model_num=6, flags=0, light=..., glow_values=0xbeffefb4, alt_textures=0x0)
    at main/polyobj.c:575
#5  0x000cb446 in draw_polygon_object (obj=0xe1fa84 <Objects+17024>)
    at main/object.c:530
#6  0x000cb7ce in render_object (obj=0xe1fa84 <Objects+17024>)
    at main/object.c:749
#7  0x000e0dcc in do_render_object (objnum=28, window_num=0)
    at main/render.c:699
#8  0x000e3740 in render_mine (start_seg_num=13, eye_offset=0, window_num=0)
    at main/render.c:2223
#9  0x000e26da in render_frame (eye_offset=0, window_num=0)
    at main/render.c:1706
#10 0x0005e394 in game_render_frame_mono (flip=1) at main/gamerend.c:676
#11 0x0005e880 in game_render_frame () at main/gamerend.c:796
#12 0x00052596 in game_handler (wind=0x1751448, event=0xbefff154, data=0x0)
    at main/game.c:1132
#13 0x00019fec in window_send_event (wind=0x1751448, event=0xbefff154)
    at arch/sdl/window.c:211
#14 0x000171ca in event_process () at arch/sdl/event.c:165
#15 0x000885b8 in main (argc=4, argv=0xbefff304) at main/inferno.c:472
This seems quite different in flavour to my earlier problems. Judging by the messages, could this hiccup be graphical in nature?
Reply
#17
That is definitely in the rendering code, so it is graphical in nature.  Are you sure this is really a segmentation fault this time?  You previously reported a crash as a segmentation fault, but it turned out to be a bus error.  The two have very different causes and require different forms of investigation to understand.
Reply
#18
Your suspicions are most probably right, Kp. On closer inspection, gdb is still reporting a SIGBUS bus error. Perhaps the generic 'Segmentation Fault' D2X returns to the terminal is a misnomer in this respect.
Whatever is causing the problem is restricted to polygonal models: I find that I am always able to replicate the crash upon entering the Polygon Models Viewer within the Sandbox menu.
Reply
#19
I would recommend to look at which assember instruction actually triggers the crash (gdb can tell you), what adresses are involved and what the alignment rules actually are.
"Perfection is attained not when there is nothing more to add, but when there is nothing more to remove." -- Antoine de Saint Exupéry
Reply
#20
(03-14-2014, 11:18 PM)fish link Wrote: Your suspicions are most probably right, Kp. On closer inspection, gdb is still reporting a SIGBUS bus error. Perhaps the generic 'Segmentation Fault' D2X returns to the terminal is a misnomer in this respect.
Whatever is causing the problem is restricted to polygonal models: I find that I am always able to replicate the crash upon entering the Polygon Models Viewer within the Sandbox menu.
D2X does not return anything to the terminal.  That is output from your shell in response to the exit status of the crashed process.  Looking at your strace, the misleading output appears to be a bug in PulseAudio.  First you get a SIGBUS, then instead of dying properly, PulseAudio steps in, unlinks a file, and then crashes with a SIGSEGV.  That SIGSEGV then tricks your shell into printing "Segmentation fault" instead of the proper "Bus error."  If you uninstall PulseAudio, do you get the proper output of "Bus error" when the program crashes?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)