Modding, Mission Design, and Coding > Cross-Platform Development
FS2 on arm
Steel01:
Since the last arm discussion is pretty old, I figured I should open a new topic. So, I have a Nvidia Shield Tablet. Pretty fancy Android tablet with full opengl 4.5 support. Recently, someone got the Ubuntu distro made for the Jetson dev board booting on the tablet with full video acceleration. Just about the first thing I did was try to get d2x-xl to run, but didn't get very far (video driver crash loading mission). Next attempt was fs2_open. I had to make a slight tweak to configure.ac, but after that it compiled fine. With stock data files, it runs well. Like 60-80 fps in the first real mission well. Then I loaded up the 2014 mediavps and things started going downhill. Loading a briefing causes a SIGBUS. Dmesg gives me:
--- Code: ---[ 1451.767551] Alignment trap: not handling instruction ed937a00 at [<005f3704>]
[ 1451.774786] Unhandled fault: alignment exception (0x221) at 0x025d604f
--- End code ---
Gdb gives:
--- Code: ---Program received signal SIGBUS, Bus error.
0x005f3708 in point_in_octant (pm=0x23fffd0, oct=0x2401c24, vert=0x25d604f) at model/modeloctant.cpp:28
28 if ( vert->xyz.x < oct->min.xyz.x ) return 0;
--- End code ---
Some googling indicates a misaligned pointer. But the compiler flag -mno-unaligned-access is supposed to fix that. But it had no effect. I'm not entirely convinced the compiler isn't at fault, though. I'm posting to see if anyone here has an idea before I go much further. This is all with trunk as of yesterday. I've also attached a debug log from my last run.
Steel01
Edit: Doing some more poking around. I get the same thing when using the model viewer room too. It's always crashing in modeloctant line28. Starting to poke at the code, it appears the modeloctant functions do some pointer arithmetic that my arm cortex doesn't appreciate. Specifically the vert pointer. It appears to be all aligned on 4's, though. I don't know what the processor expects. Continuing to debug. Side note: all this goes away if I remove the effects and assets vps. Something in those files kicks the program down a different code path that causes the SIGBUS.
Edit 2: Wow, -Wcast-align gives 260 hits (well, grep -c align does on the build log). This could take a bit of work. I'll see if I can't get it running. I'm rather surprised now that it runs at all, even with just stock assets.
[attachment kidnapped by pirates]
chief1983:
I wonder if this is something AddressSanitizer could help with.
Steel01:
Asan doesn't like this code at all. On my arm box, it dies with what appears to be a null pointer dereference and even the stack trace gets lost. On my x86_64 Fedora 21 machine, it dies in short order with a free on non-malloced address, but at least that one is tracable.
I've been trying to do some research on memory alignment. Some interesting reads out there. Seems x86 lets programmers get away with murder and just covers for them by doing multiple memory reads and shifting to return what should have been a one asm instruction mem read. Arm, among other platforms, throws a SIGBUS on such attempts. So, I'm starting to get an idea of what the problem is. Next problem is to figure out what the affected code is supposed to be doing to figure out a patch. Memcopying the bad data to new, aligned regions would probably work, but is an ugly, slow hack. Though I might try that in a couple places just to see if that stops the crash.
For reference, I'm attaching the stderr of an arm build with -Wcast-align.
Steel01
[attachment kidnapped by pirates]
chief1983:
Hmm, ASan has worked reasonably well for me in the past, not sure why you'd have such rough luck with it on x86 unless we've introduced a major bug recently. Could be possible. As for ARM, yeah no idea how it would behave there. Interested to hear about your findings though.
Steel01:
It's something to do with audio. Without ASan, it runs fine, so it *shouldn't* be a system problem, but it does trace through openal...
--- Code: ---=================================================================
==3276==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000003b9b010 in thread T0
#0 0x7f92d9c2753f in __interceptor_free (/lib64/libasan.so.1+0x5753f)
#1 0x360ac2abea in alcCloseDevice (/lib64/libopenal.so.1+0x360ac2abea)
#2 0xe24f39 in openal_init_device(std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >*, std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >*) sound/openal.cpp:392
#3 0xe1687f in ds_init() sound/ds.cpp:1061
#4 0xe29a9b in snd_init() sound/sound.cpp:147
#5 0x413987 in game_init() freespace2/freespace.cpp:1853
#6 0x429b26 in game_main(char*) freespace2/freespace.cpp:7096
#7 0x42a33b in main freespace2/freespace.cpp:7288
#8 0x35efc1ffdf in __libc_start_main (/lib64/libc.so.6+0x35efc1ffdf)
#9 0x40cba4 (/usr/local/games/fs2_open/fs2_open_3.7.1_DEBUG+0x40cba4)
AddressSanitizer can not describe address in more detail (wild memory access suspected).
SUMMARY: AddressSanitizer: bad-free ??:0 __interceptor_free
==3276==ABORTING
--- End code ---
My spare time comes and goes, so I haven't had time to dig into the code for the alignment stuff yet. Should have some time in the next three or four days, though.
Steel01
Edit: I suppose the above is a bad argument. But I haven't had problems with openal. 'Course I haven't tried to use ASan on anything before either.
Navigation
[0] Message Index
[#] Next page
Go to full version