Re: malloc crash

[Ken Brown <kbrown@cornell.edu>]

On 10/25/2021 4:59 AM, Corinna Vinschen wrote:
> 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?

Yes, here's the backtrace of that thread:

Thread 5 (Thread 9692.0x7c4c):
#0  0x00000001801934f9 in sys_alloc (m=0x18036f860 <_gm_>, nb=1040) at 
../../../../temp/winsup/cygwin/malloc.cc:4232
#1  0x0000000180196b96 in dlmalloc (bytes=1024) at 
../../../../temp/winsup/cygwin/malloc.cc:4669
#2  0x00000001801993e1 in dlrealloc (oldmem=0x0, bytes=1024) at 
../../../../temp/winsup/cygwin/malloc.cc:5187
#3  0x00000001800e8eed in realloc (p=0x0, size=1024) at 
../../../../temp/winsup/cygwin/malloc_wrapper.cc:73
#4  0x000000018008b6c4 in fhandler_fifo::add_client_handler (this=0x1803a0d80, 
new_pipe_instance=false) at ../../../../temp/winsup/cygwin/fhandler_fifo.cc:330
#5  0x000000018008b9ee in fhandler_fifo::update_my_handlers (this=0x1803a0d80) 
at ../../../../temp/winsup/cygwin/fhandler_fifo.cc:407
#6  0x000000018008bfe6 in fhandler_fifo::fifo_reader_thread_func 
(this=0x1803a0d80) at ../../../../temp/winsup/cygwin/fhandler_fifo.cc:531
#7  0x000000018008bcda in fifo_reader_thread (param=0x1803a0d80) at 
../../../../temp/winsup/cygwin/fhandler_fifo.cc:453
#8  0x000000018004684f in cygthread::callfunc (this=0x180276620 <threads>, 
issimplestub=false) at ../../../../temp/winsup/cygwin/cygthread.cc:48
#9  0x0000000180046a25 in cygthread::stub (arg=0x180276620 <threads>) at 
../../../../temp/winsup/cygwin/cygthread.cc:91
#10 0x000000018004771c in _cygtls::call2 (this=0x114ce00, func=0x180046856 
<cygthread::stub(void*)>, arg=0x180276620 <threads>, buf=0x114cce0) at 
../../../../temp/winsup/cygwin/cygtls.cc:40
#11 0x00000001800476c1 in _cygtls::call (func=0x180046856 
<cygthread::stub(void*)>, arg=0x180276620 <threads>) at 
../../../../temp/winsup/cygwin/cygtls.cc:27
#12 0x00000001800e4e65 in threadfunc_fe (arg=0x180276620 <threads>) at 
../../../../temp/winsup/cygwin/init.cc:28
#13 0x00007ffe94c27034 in KERNEL32!BaseThreadInitThunk () from 
/c/WINDOWS/System32/KERNEL32.DLL
#14 0x00007ffe950a2651 in ntdll!RtlUserThreadStart () from 
/c/WINDOWS/SYSTEM32/ntdll.dll
#15 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

It's also trying to allocate memory.  Is this a race between two threads 
allocating memory?

Ken