On 7/25/2013 18:18, JonY wrote: > 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. > >
Daniel, please apply for FSF copyright assignment if you have not already done so, if not, this patch is not going to be accepted upstream.
signature.asc
Description: OpenPGP digital signature
