Something like Valgrind might spot some initial problem that doesn't immediately crash but eventually spirals out of control. It seems to support ARM linux now:
"20 October 2016: valgrind-3.12.0 is available. This release supports: X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, X86/MacOSX 10.10 and AMD64/MacOSX 10.10. There is also preliminary support for X86/MacOSX 10.11/12, AMD64/MacOSX 10.11/12 and TILEGX/Linux. For more details see the release notes <http://valgrind.org/docs/manual/dist.news.html>." I don't know what the gcc version is on your Pi but if you have a recent enough one you might manage to use the address sanitiser option to get a similar result. Regards, Tim On 12 November 2016 at 14:30, Paul Smith <psm...@gnu.org> wrote: > On Fri, 2016-11-11 at 19:41 +0200, Jaak Ristioja wrote: > > After examining about 10 more core files, these all point to job.c:519 > > and job.c:537, similarly to the above: > > > > #0 0x00c2bd74 in child_error (child=0x0, exit_code=0, exit_sig=0, > > coredump=0, ignored=0) at job.c:519 > > pre = 0x0 > > post = 0x0 > > dump = 0x0 > > f = 0x0 > > flocp = 0x0 > > nm = 0x0 > > l = 0 > > #1 0x00c2bd8e in child_handler (sig=0) at job.c:537 > > No locals. > > #2 0x00c67cc0 in ?? () > > No symbol table info available. > > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > > > > Any ideas? > > Unfortunately this doesn't help much. It's pretty clear that either ARM > debug information is very limited, or GDB is problematic on ARM, or else > the core file is very corrupted: there's no way that all the values in > the argument lists to these functions are really 0/NULL. Also, as you > point out, in no way does child_handler() (which is a signal handler) > ever call child_error(). > > In fact, if your config.h from GNU make has HAVE_PSELECT set (which I > would expect it would since this is Linux) there's no way the > child_handler() function should ever be invoked at all. > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make >
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
