Re: malloc crash

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Oct 24 17:46, Ken Brown wrote:
> I'm trying to debug the fifo problem reported here:
> 
>   https://cygwin.com/pipermail/cygwin/2021-October/249635.html
> 
> To keep my email self-contained, here are the reproduction instructions.
> Run the attached script with argument 1000.  The output is supposed to look
> like this:
> [...]
>     func=0x18004a218 <dll_crt0_1(void*)>, arg=0x0, buf=0xffffcdb0)
>     at ../../../../temp/winsup/cygwin/cygtls.cc:40
> #17 0x00000001800476c1 in _cygtls::call (func=0x18004a218 <dll_crt0_1(void*)>,
>     arg=0x0) at ../../../../temp/winsup/cygwin/cygtls.cc:27
> #18 0x000000018004aac9 in _dll_crt0 ()
>     at ../../../../temp/winsup/cygwin/dcrt0.cc:1099
> #19 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Typing 'finish' enough times until it won't return anymore shows that there
> is an infinite loop starting with an access violation here:
> 
> (gdb) f 8
> #8  0x0000000180191a5c in init_top (m=0x18036f860 <_gm_>, p=0x800010000,
>     psize=65456) at ../../../../temp/winsup/cygwin/malloc.cc:3903
> 3903      p->head = psize | PINUSE_BIT;

The address p=0x800010000 indicates that this malloc tries to alloc heap
space, and the address 0x800010000 is right at the start.  Exec'd
process, so this SEGV is rather strange, becasue that would mean this
part of the VM isn't commited.  How's that supposed to happen?  Malloc
should have called sbrk before, which in turn would have committed this
part of the heap.  Puzzeling.

> If I'm reading the backtrace correctly, the access violation occurs while
> Cygwin is trying to allocate storage for the main thread object of the
> exec'd process.

Looks like it, yes.

> I'm not familiar enough with the relevant Cygwin internals to take the
> analysis any further, but my guess is that the problem is somehow triggered
> by the creation of a new thread at the end of
> fhandler_fifo::fixup_after_exec:
> 
>       new cygthread (fifo_reader_thread, this, "fifo_reader", thr_sync_evt);
> 
> Is this a bug in the fifo code?  Is there some reason I shouldn't be
> creating a new thread in fixup_after_exec?

I'm not aware of any.  Starting cygthreads is an integral part of
process startup, e. g., the wait_sig thread.

Has the thread already been started at this point?


Corinna