From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23702 invoked by alias); 25 Jul 2013 08:36:59 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 23674 invoked by uid 89); 25 Jul 2013 08:36:59 -0000 X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_50,KHOP_PGP_SIGNED,KHOP_THREADED,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO dancol.org) (96.126.100.184) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 25 Jul 2013 08:36:58 +0000 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[0.0.0.0]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1V2H2Z-0008NL-3J for cygwin@cygwin.com; Thu, 25 Jul 2013 01:36:51 -0700 Message-ID: <51F0E39C.1090500@dancol.org> Date: Thu, 25 Jul 2013 10:18:00 -0000 From: Daniel Colascione User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: python aborts References: <20130522123148.GW2406@calimero.vinschen.de> <51F0CBD2.2030502@dancol.org> <51F0CF92.60009@dancol.org> In-Reply-To: <51F0CF92.60009@dancol.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ABQHNUQBBPRONOGPTBAE" X-Virus-Found: No X-SW-Source: 2013-07/txt/msg00530.txt.bz2 ------enig2ABQHNUQBBPRONOGPTBAE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-length: 2664 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 recom= piled >> _wp.dll using gcc 4.7.3. >=20 > Actually, this problem looks a lot like > http://www.mail-archive.com/gcc@gcc.gnu.org/msg68316.html: neither Python= nor > _wp links dynamically to libgcc, but cygsqlite3-0.dll does. >=20 And this is a very nasty bug; Eli's analysis is correct. Say we have module= s 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, fi= nds them uninitialized, and aborts. No wonder changing Python module order arou= nd makes the problem go away for a little while. The right fix for libgcc looks something like this: --- 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 =3D GetModuleHandle (LIBGCC_SONAME); if (h) - register_frame_fn =3D (void (*) (const void *, struct object *)) - GetProcAddress (h, "__register_frame_info"); + { + libgcc_dll =3D LoadLibrary (LIBGCC_SONAME); /* Hold reference */ + register_frame_fn =3D (void (*) (const void *, struct object *)) + GetProcAddress (h, "__register_frame_info"); + } else register_frame_fn =3D __register_frame_info; if (register_frame_fn) @@ -124,13 +129,16 @@ { #if DWARF2_UNWIND_INFO void * (*deregister_frame_fn) (const void *); - HANDLE h =3D GetModuleHandle (LIBGCC_SONAME); - if (h) + if (libgcc_dll) deregister_frame_fn =3D (void* (*) (const void *)) - GetProcAddress (libgcc_dl, "__deregister_frame_in= fo"); + GetProcAddress (libgcc_dll, "__deregister_frame_info"); else deregister_frame_fn =3D __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 sh= ared libgcc is pinned in memory. ------enig2ABQHNUQBBPRONOGPTBAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 260 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHw46EACgkQ17c2LVA10VsFqgCghMdWq6PmEyzV2g/pq0JLJuAl L44An3lKidwalpf3+DiJWDXivHOCbjf9 =zjwt -----END PGP SIGNATURE----- ------enig2ABQHNUQBBPRONOGPTBAE--