malloc crash

Ken Brown
Mon Oct 25 12:35:01 GMT 2021

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:
>> 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/
>> #17 0x00000001800476c1 in _cygtls::call (func=0x18004a218 <dll_crt0_1(void*)>,
>>      arg=0x0) at ../../../../temp/winsup/cygwin/
>> #18 0x000000018004aac9 in _dll_crt0 ()
>>      at ../../../../temp/winsup/cygwin/
>> #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/
>> 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 
#1  0x0000000180196b96 in dlmalloc (bytes=1024) at 
#2  0x00000001801993e1 in dlrealloc (oldmem=0x0, bytes=1024) at 
#3  0x00000001800e8eed in realloc (p=0x0, size=1024) at 
#4  0x000000018008b6c4 in fhandler_fifo::add_client_handler (this=0x1803a0d80, 
new_pipe_instance=false) at ../../../../temp/winsup/cygwin/
#5  0x000000018008b9ee in fhandler_fifo::update_my_handlers (this=0x1803a0d80) 
at ../../../../temp/winsup/cygwin/
#6  0x000000018008bfe6 in fhandler_fifo::fifo_reader_thread_func 
(this=0x1803a0d80) at ../../../../temp/winsup/cygwin/
#7  0x000000018008bcda in fifo_reader_thread (param=0x1803a0d80) at 
#8  0x000000018004684f in cygthread::callfunc (this=0x180276620 <threads>, 
issimplestub=false) at ../../../../temp/winsup/cygwin/
#9  0x0000000180046a25 in cygthread::stub (arg=0x180276620 <threads>) at 
#10 0x000000018004771c in _cygtls::call2 (this=0x114ce00, func=0x180046856 
<cygthread::stub(void*)>, arg=0x180276620 <threads>, buf=0x114cce0) at 
#11 0x00000001800476c1 in _cygtls::call (func=0x180046856 
<cygthread::stub(void*)>, arg=0x180276620 <threads>) at 
#12 0x00000001800e4e65 in threadfunc_fe (arg=0x180276620 <threads>) at 
#13 0x00007ffe94c27034 in KERNEL32!BaseThreadInitThunk () from 
#14 0x00007ffe950a2651 in ntdll!RtlUserThreadStart () from 
#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?


More information about the Cygwin-developers mailing list