Tue Oct 26 09:24:49 GMT 2021
On Oct 25 18:02, Ken Brown wrote:
> On 10/25/2021 5:29 PM, Mark Geisert wrote:
> > Corinna Vinschen wrote:
> > > On Oct 25 08:35, Ken Brown wrote:
> > > > On 10/25/2021 4:59 AM, Corinna Vinschen wrote:
> > > > > 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
> > >
> > > Er... huh? So both threads are in a malloc function? This shouldn't
> > > have happened, given the clunky muto guarding malloc calls. This is
> > > really strange. Why's the muto not working here?
> > Is it possible both threads have executed malloc_init()?
> > If so, the second one would reinit the muto.
Right, but malloc_init is only called from dll_crt0_1, so only the main
thread can actually call malloc_init, other threads never get there.
> Or does the fifo_reader thread call a malloc function before the main thread
> has called malloc_init()? This would presumably cause __malloc_lock() to
> fail, but there's no error check.
That sounds more likely. In theory this shouldn't have much influence,
though. First of all, all fixup calls are running in a single thread,
so there's no serialization required(*), and the malloc_init call
doesn't set up the malloc arena, it just initializes the muto and checks
for user space provided malloc calls, which is not a problem in this
(*) unless multiple threads are started during fixup and some of these
threads mallocate memory again...
Ken, is there a chance to tweak the fifo code to stop creating
threads from inside fixup, and to defer the thread start to the first
call in the process actually relying on the thread being started?
More information about the Cygwin-developers