X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=nTRlmhP+pHBSTEc2LCrrE0oJwbxCS8jkEXJT1Z0G9G6cz1hTcgRAD twQwHomG8XpBuqrfN5wMjm47zzySWteHPQ7AjZ++/jMn/nuY/nYovOfI+k8QX4rH mM/hROE3iVlPVdpZLqEfjFd1L0HYB2WHeIvP1hboyXSXB9v2QrRzi4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=fRNfPwnoazwJZjDmDLEikcl7c7Q=; b=QTZ5dCpBS5fdwWgjYDzIC2LA6Vpb 6baGATmQBgp/64PYKSntYCZPAK/LsyaNofjV7Fr56LXsZlKNpxVoCbeLvv3ZX0VW Yvck6/T2ZmXxmnk1rJso34W0LJxfuJ4Ka5eAurSy1W6W2MN2kA+Y7aj8bf3jpNQv TIyz3+8gZRtI+aA= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE autolearn=no version=3.3.1 Date: Thu, 25 Jul 2013 11:17:41 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: python aborts Message-ID: <20130725091741.GA20682@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20130522123148 DOT GW2406 AT calimero DOT vinschen DOT de> <51F0CBD2 DOT 2030502 AT dancol DOT org> <51F0CF92 DOT 60009 AT dancol DOT org> <51F0E39C DOT 1090500 AT dancol DOT org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51F0E39C.1090500@dancol.org> User-Agent: Mutt/1.5.21 (2010-09-15) On Jul 25 01:36, Daniel Colascione wrote: > On 7/25/2013 12:11 AM, Daniel Colascione wrote: > > On 7/24/2013 11:55 PM, Daniel Colascione wrote: > >> Does that help at all? I only started seeing this problem after I recompiled > >> _wp.dll using gcc 4.7.3. > > > > Actually, this problem looks a lot like > > http://www.mail-archive.com/gcc AT gcc DOT gnu DOT org/msg68316.html: neither Python nor > > _wp links dynamically to libgcc, but cygsqlite3-0.dll does. > > > > And this is a very nasty bug; Eli's analysis is correct. Say we have modules Foo > and Bar. Foo links against shared libgcc, but Bar does not. Now, if we load Foo, > load Bar, unload Foo, then unload Bar, then Foo's initialization code finds > libgcc and registers itself with it, but Foo's deinitializaton code doesn't find > libgcc, tries to instead unregister with Foo's internal data structures, finds > them uninitialized, and aborts. No wonder changing Python module order around > makes the problem go away for a little while. > > The right fix for libgcc looks something like this: Good catch! Any chance you could send this upstream? JonY, do you have any spare cycles to create new 32 and 64 bit gcc packages with this fix? Thanks, Corinna > --- config/i386/cygming-crtbegin.c.orig 2013-07-25 00:07:35.000000000 -0800 > +++ config/i386/cygming-crtbegin.c 2013-07-25 00:33:11.000000000 -0800 > @@ -82,6 +82,8 @@ > extern void __gcc_register_frame (void); > extern void __gcc_deregister_frame (void); > > +static HANDLE libgcc_dll; > + > void > __gcc_register_frame (void) > { > @@ -94,8 +96,11 @@ > void (*register_frame_fn) (const void *, struct object *); > HANDLE h = GetModuleHandle (LIBGCC_SONAME); > if (h) > - register_frame_fn = (void (*) (const void *, struct object *)) > - GetProcAddress (h, "__register_frame_info"); > + { > + libgcc_dll = LoadLibrary (LIBGCC_SONAME); /* Hold reference */ > + register_frame_fn = (void (*) (const void *, struct object *)) > + GetProcAddress (h, "__register_frame_info"); > + } > else > register_frame_fn = __register_frame_info; > if (register_frame_fn) > @@ -124,13 +129,16 @@ > { > #if DWARF2_UNWIND_INFO > void * (*deregister_frame_fn) (const void *); > - HANDLE h = GetModuleHandle (LIBGCC_SONAME); > - if (h) > + if (libgcc_dll) > deregister_frame_fn = (void* (*) (const void *)) > - GetProcAddress (libgcc_dl, "__deregister_frame_info"); > + GetProcAddress (libgcc_dll, "__deregister_frame_info"); > else > deregister_frame_fn = __deregister_frame_info; > if (deregister_frame_fn) > deregister_frame_fn (__EH_FRAME_BEGIN__); > + > + if (libgcc_dll) > + FreeLibrary (libgcc_dll); > + > #endif > > The problem is that this code is baked into every module compiled with the buggy > libgcc. You have to recompile the world to fix it for good --- except if shared > libgcc is pinned in memory. > -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple