Re: INTERNAL: Exiting with 2 jobserver tokens available; should be 5!

[Tim Murphy]

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."

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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-make