Andy Green wrote: > On 01/07/11 00:34, Somebody in the thread at some point said: > > Hi - > >> Program received signal SIGSEGV, Segmentation fault. >> 0x00008230 in ?? () >> (gdb) backtrace >> Cannot access memory at address 0x0 >> #0 0x00008230 in ?? () >> #1 0x000081dc in __libc_exit (code=0) at lib/atexit.c:25 >> #2 0x00008104 in _start () at arm/start.S:34 >> >> So the problem seems to be in arm/start.S on line 34. > > No, the backtrace starts with the deepest call. D'oh! Caffeine underflow error. :'( > The problem is inside __libc_exit we end up at 0x8230 and then jump to > 0x0. 0x8230 looks fairly sane as an address so you need to disassemble > from a bit before there and see what you see. > >> It's almost half tempting to install the broken build for dependency's >> sake and see if util-vserver actually trips any of it at run-time. But I >> am a little concerned WRT whether this actually works and passes all >> self-tests even on x86 Fedora. > > It might be worth asking the dietlibc dude if the tests are even > expected to work OK on ARM. I saw he has a FAQ explaining why "this > variable may be used uninitialized" warnings are WONTFIX because he > thinks they save a byte or two, that is not the best sign. That doesn't sound too promising. My motivation to debug code of that nature is rapidly fading, not least because it turns out that the reason I needed dietlibc has disappeared - it turns out util-vserver package that I need it for will happily build against the standard full-fat libc. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
