bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jaak Ristioja
Subject: Re: INTERNAL: Exiting with 2 jobserver tokens available; should be 5!
Date: Fri, 11 Nov 2016 19:41:56 +0200

On 10.11.2016 09:55, Jaak Ristioja wrote:
> 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.

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?
J



reply via email to

[Prev in Thread] Current Thread [Next in Thread]