public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: malloc crash
Date: Tue, 26 Oct 2021 11:24:49 +0200	[thread overview]
Message-ID: <YXfJYd5qMwDf2Uav@calimero.vinschen.de> (raw)
In-Reply-To: <4b322eb0-4941-6b8f-6f46-aa76caf5a66f@cornell.edu>

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
scenario.

(*) 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?


Corinna

  parent reply	other threads:[~2021-10-26  9:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-24 21:46 Ken Brown
2021-10-25  8:56 ` Takashi Yano
2021-10-25 13:37   ` Ken Brown
2021-10-25  8:59 ` Corinna Vinschen
2021-10-25 12:35   ` Ken Brown
2021-10-25 15:39     ` Corinna Vinschen
2021-10-25 21:29       ` Mark Geisert
2021-10-25 22:02         ` Ken Brown
2021-10-25 23:36           ` Mark Geisert
2021-10-26  0:18             ` Takashi Yano
2021-10-26  0:54               ` Mark Geisert
2021-10-26  8:30                 ` Mark Geisert
2021-10-26  8:52                   ` Takashi Yano
2021-10-26  8:59                     ` Mark Geisert
2021-10-26  9:26                       ` Takashi Yano
2021-10-26  9:31                         ` Corinna Vinschen
2021-10-26  9:28                       ` Corinna Vinschen
2021-10-26  9:27                 ` Corinna Vinschen
2021-10-26  9:24           ` Corinna Vinschen [this message]
2021-10-26 14:32             ` Ken Brown
2021-10-26 16:03               ` Corinna Vinschen
2021-10-26 16:36                 ` Ken Brown
2021-10-26 16:49                   ` Corinna Vinschen
2021-10-26 17:10                     ` Ken Brown
2021-10-27  0:44                     ` Takashi Yano
2021-10-27  9:01                       ` Corinna Vinschen
2021-10-26 16:44                 ` Takashi Yano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXfJYd5qMwDf2Uav@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-developers@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).