From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-05.nifty.com (conssluserg-05.nifty.com [210.131.2.90]) by sourceware.org (Postfix) with ESMTPS id 0318E3858C27 for ; Tue, 26 Oct 2021 00:19:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0318E3858C27 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-05.nifty.com with ESMTP id 19Q0IkSA019267 for ; Tue, 26 Oct 2021 09:18:47 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 19Q0IkSA019267 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1635207527; bh=L19XafVFEFZvWsld/DV3BdRJWWnBTbU37melGjxqbLg=; h=Date:From:To:Subject:In-Reply-To:References:From; b=z/dcmHdQuwXUIxLPSiCisiJvMtRUfdG9ec0aq6gguZdPKGufRL5wwSXIMxTUTBy8B qZXZcSpPgb925r1ir68CjR15tDwlcxRilkkpchuDpL10vnSxj2yPJzvUCe+uxsc7mm UWvBYtuFDrBreH2encg6V92fFN6Q0BszddFA+D2zg2tluMjMG3yq5688DG8cnGjl+i xN/ngNC20cie5MX4s2sIPFuacdImkt0bGuQTpqqBnTF9QbQE71dgIiT6VBktjY8fuX 5wVNpzpbkklqM63suRJdgQ0wQLS2bNgSO3+d1GMeKp2Te5NbaKVYt6wokx+s/W2KaT +ZwQX9/4k6jGQ== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 26 Oct 2021 09:18:55 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: malloc crash Message-Id: <20211026091855.7aaf2de97d10174121cbc8f9@nifty.ne.jp> In-Reply-To: <2819d0db-3c5c-2d31-2b21-91efafb7f8f4@maxrnd.com> References: <6a4d6675-7e4d-bcb3-9aff-acc0788d211d@cornell.edu> <97873b16-7ec3-02d7-1861-3ec62a79c37e@cornell.edu> <4b322eb0-4941-6b8f-6f46-aa76caf5a66f@cornell.edu> <2819d0db-3c5c-2d31-2b21-91efafb7f8f4@maxrnd.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 00:19:10 -0000 On Mon, 25 Oct 2021 16:36:50 -0700 Mark Geisert wrote: > 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. > > > > 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. > > If there's a global constructor involved, that is known to happen. Constructors > are run from dll_crt0_0(), before malloc_init() is called from dll_crt0_1(). See > dcrt0.cc for the details. So how about moving malloc_init() call from dll_crt0_1() to dll_crl0_0() so that malloc() can be called in fixup_after_fork/exec()? -- Takashi Yano