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: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 <corinna-cygwin AT cygwin DOT com>
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: <d0191e464b44f772f988b2050cda4ac8 AT denis-excoffier DOT org> <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