On 7/25/2013 17:17, Corinna Vinschen wrote: > 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@gcc.gnu.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 >
Sure, should be done during the weekends, uploads and all. Kai seems to be on holiday, so getting it accepted upstream might take a while.
signature.asc
Description: OpenPGP digital signature
