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

[Jaak Ristioja]

On 11.11.2016 19:41, Jaak Ristioja wrote:
> 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?

Looking at the code, job.c (and other source code files in GNU Make)
uses alloca (3) to allocate memory!? This is definitely looks like one
possible source for stack overflows! Quoting `man 3 alloca`:

    BUGS:
        There is no error indication if the stack frame cannot
        be extended. (However, after a failed allocation, the
        program is likely to receive a SIGSEGV signal if it
        attempts to access the unallocated space.)

Personally, I would never use this function in regular code. In
child_error() it is used to allocate enough space for a filename:

    char *a = alloca (strlen (flocp->filenm) + 1 + 11 + 1);

Assuming that flocp->filenm points to a path and not just the name of
the single file, one could easily overflow that stack, IMHO. I'm
guessing that PATH_MAX is 4096 on most Linux systems, while the stack is
8192.

Are you sure this is safe?

J