On 09.11.2016 22:58, Paul Smith wrote: > On Wed, 2016-11-09 at 22:42 +0200, Jaak Ristioja wrote: >> I have no ARM experience myself. I don't even know where to look for >> ABI >> documentation. This is the best I can currently get from the core: >> >> (gdb) thread apply all bt full >> >> Thread 1 (LWP 15210): >> #0 0x0d33b0bc in ?? () >> No symbol table info available. >> #1 <signal handler called> >> No symbol table info available. >> #2 0x64a2a8b0 in strlen () from /lib/libc.so.6 >> No symbol table info available. >> #3 0x0d340370 in concat () >> No symbol table info available. >> #4 0x0d680d34 in ?? () >> No symbol table info available. >> Backtrace stopped: previous frame identical to this frame (corrupt >> stack?) > > You won't need any ABI docs. This is a good first step, but if you can > rebuild GNU make with debugging (-g) and without optimization (-O0) you > will hopefully get a much more interesting and useable core. I'm > assuming, although I'm not familiar with working on ARM. > > It looks like somewhere in the GNU make code we're passing an invalid > pointer to strlen(); either NULL or pointing to invalid memory of some > kind.
After re-compiling make 4.2.1 with "-O0 -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ggdb" instead of the regular "-O2 -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" I got: Thread 1 (LWP 20416): #0 0x0c5cbd74 in child_error (child=0xbf78e700, exit_code=1900259124, exit_sig=-1082595584, coredump=1900259184, ignored=0) at job.c:519 #1 0x0c5cbd8e in child_handler (sig=1935828325) at job.c:537 #2 0x00000008 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Which looks even more weird. I'm not even sure its the same crash. Something seriously seems to corrupt the stack in both cases. As far as I can tell, child_handler() does not call child_error() directly or indirectly. J _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make