python aborts

python aborts

[Denis Excoffier]

Hello,

With the current snapshot (20130521) on Windows XP, the following fails 
(with an empty stackdump):

% /usr/bin/python pyfoo
Abort (core dumped)
% cat pyfoo
import xml.sax
xml.sax.make_parser()
% cat python2.7.exe.stackdump
Stack trace:
Frame     Function  Args
% /usr/bin/python --version
Python 2.7.3
%

With some dichotomy, i found that under the 20130430 snapshot it works
(no "abort", no stackdump), but under 20130501 it does the same
as today (ie abort).

My original python program (from which i extracted this test case) 
seems
to run correctly until the end of it, where the abort occurs.

Regards,

Denis Excoffier.

--
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

Re: python aborts

[Corinna Vinschen]

On May 22 11:11, Denis Excoffier wrote:
> Hello,
> 
> With the current snapshot (20130521) on Windows XP, the following
> fails (with an empty stackdump):
> 
> % /usr/bin/python pyfoo
> Abort (core dumped)
> % cat pyfoo
> import xml.sax
> xml.sax.make_parser()
> % cat python2.7.exe.stackdump
> Stack trace:
> Frame     Function  Args
> % /usr/bin/python --version
> Python 2.7.3
> %
> 
> With some dichotomy, i found that under the 20130430 snapshot it works
> (no "abort", no stackdump), but under 20130501 it does the same
> as today (ie abort).

I have another effect.  In my case the 20130430 snapshot does not
print the "Abort (core dumped)" message, but it still creates the
more or less empty stackdump file as above.  So, AFAICS, the crash
occured before, only you didn't see it.  With Cygwin 1.7.17,
I only get an "Abort" and an entirely empty stackdump.

> My original python program (from which i extracted this test case)
> seems
> to run correctly until the end of it, where the abort occurs.

Well, I'm not sure what's going on, but the crash supposedly occurs
in verifyable_object_isvalid in thread.cc.  This function is usually
called to check if a pthreads object is valid, and it's written so
that a SEGV is expected, catched, and converted to a specific return
code, usually.  Even with a debug-enabled Cygwin DLL I'm not able
to debug this further since python somehow doesn't run the same under
GDB.


Corinna

-- 
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

Re: python aborts

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

I just started seeing this problem myself --- on 1.7.22 release.

On 5/22/2013 5:31 AM, Corinna Vinschen wrote:
> On May 22 11:11, Denis Excoffier wrote:
>> Hello,
>>
>> With the current snapshot (20130521) on Windows XP, the following
>> fails (with an empty stackdump):
>>
>> % /usr/bin/python pyfoo
>> Abort (core dumped)
>> % cat pyfoo
>> import xml.sax
>> xml.sax.make_parser()
>> % cat python2.7.exe.stackdump
>> Stack trace:
>> Frame     Function  Args
>> % /usr/bin/python --version
>> Python 2.7.3
>> %
>>
>> With some dichotomy, i found that under the 20130430 snapshot it works
>> (no "abort", no stackdump), but under 20130501 it does the same
>> as today (ie abort).
> 
> I have another effect.  In my case the 20130430 snapshot does not
> print the "Abort (core dumped)" message, but it still creates the
> more or less empty stackdump file as above.  So, AFAICS, the crash
> occured before, only you didn't see it.  With Cygwin 1.7.17,
> I only get an "Abort" and an entirely empty stackdump.

I can run python -c 'import _wp,sqlite3' and see Python abort, but if I swap the
module order, everything seems to be fine. gdb is useless if I wait until it
breaks, but if i set a breakpoint on cygwin1!abort beforehand, I get this stack:

(gdb) where
#0  abort () at /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/signal.cc:362
#1  0xc3b05111 in cyggcc_s-1!__deregister_frame_info_bases () from
/usr/bin/cyggcc_s-1.dll
#2  0x65fc10e2 in __gcc_deregister_frame () from C:/users/dancol/wptools/_wp.dll
#3  0x610265f5 in run_dtors (this=<optimized out>)
    at /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dll_init.cc:80
#4  run_dtors (this=<optimized out>) at
/usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dll_init.h:72
#5  run_dtors (this=<optimized out>) at
/usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dll_init.cc:41
#6  dll_global_dtors () at
/usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dll_init.cc:52

Does that help at all?  I only started seeing this problem after I recompiled
_wp.dll using gcc 4.7.3.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: python aborts

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: python aborts

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

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:

--- 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: python aborts

[Corinna Vinschen]

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


> --- 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

Re: python aborts

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: python aborts

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: python aborts

[Christopher Faylor]

On Thu, Jul 25, 2013 at 06:54:03PM +0800, JonY wrote:
>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.

I'm still a (silent) gcc maintainer so I can presumably accept this patch.

Are there outstanding patches that need attention?  If so, please send URLs
from the gcc-patches archive here so that I can attend to them.

cgf

--
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

Re: python aborts

[JonY]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On 7/25/2013 23:14, Christopher Faylor wrote:
> 
> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
> 
> Are there outstanding patches that need attention?  If so, please send URLs
> from the gcc-patches archive here so that I can attend to them.
> 

This libgcc patch, and some minor patches at
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.

There are some others from Yaakov's gcc builds, but let's start with
smaller patches first.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: python aborts

[Christopher Faylor]

On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>On 7/25/2013 23:14, Christopher Faylor wrote:
>> 
>> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
>> 
>> Are there outstanding patches that need attention?  If so, please send URLs
>> from the gcc-patches archive here so that I can attend to them.
>> 
>
>This libgcc patch, and some minor patches at
>http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>
>There are some others from Yaakov's gcc builds, but let's start with
>smaller patches first.

It will probably be a couple of days before I can give these adequate
attention.

Ok to submit your name as an upstream approver, JonY?

cgf

--
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

Re: python aborts

[JonY]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On 7/26/2013 01:20, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>> On 7/25/2013 23:14, Christopher Faylor wrote:
>>>
>>> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
>>>
>>> Are there outstanding patches that need attention?  If so, please send URLs
>>> from the gcc-patches archive here so that I can attend to them.
>>>
>>
>> This libgcc patch, and some minor patches at
>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>>
>> There are some others from Yaakov's gcc builds, but let's start with
>> smaller patches first.
> 
> It will probably be a couple of days before I can give these adequate
> attention.
> 
> Ok to submit your name as an upstream approver, JonY?
> 

I have not approved any patches for GCC, not sure if I can act as
approver. Kai usually approves and commits any mingw* related gcc
patches but he is not in currently.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: python aborts

[Christopher Faylor]

On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
>On 7/26/2013 01:20, Christopher Faylor wrote:
>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>>> On 7/25/2013 23:14, Christopher Faylor wrote:
>>>>
>>>> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
>>>>
>>>> Are there outstanding patches that need attention?  If so, please send URLs
>>>> from the gcc-patches archive here so that I can attend to them.
>>>>
>>>
>>> This libgcc patch, and some minor patches at
>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>>>
>>> There are some others from Yaakov's gcc builds, but let's start with
>>> smaller patches first.
>> 
>> It will probably be a couple of days before I can give these adequate
>> attention.
>> 
>> Ok to submit your name as an upstream approver, JonY?
>> 
>
>I have not approved any patches for GCC, not sure if I can act as
>approver. Kai usually approves and commits any mingw* related gcc
>patches but he is not in currently.

Uh, yeah.  AFAIK, you aren't listed as a package approver so it would be
very difficult for you to approve anything.

Ok, nevermind.

cgf

--
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

Re: python aborts

[Christopher Faylor]

On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
>On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
>>On 7/26/2013 01:20, Christopher Faylor wrote:
>>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>>>> On 7/25/2013 23:14, Christopher Faylor wrote:
>>>>>
>>>>> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
>>>>>
>>>>> Are there outstanding patches that need attention?  If so, please send URLs
>>>>> from the gcc-patches archive here so that I can attend to them.
>>>>>
>>>>
>>>> This libgcc patch, and some minor patches at
>>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>>>>
>>>> There are some others from Yaakov's gcc builds, but let's start with
>>>> smaller patches first.
>>> 
>>> It will probably be a couple of days before I can give these adequate
>>> attention.
>>> 
>>> Ok to submit your name as an upstream approver, JonY?
>>> 
>>
>>I have not approved any patches for GCC, not sure if I can act as
>>approver. Kai usually approves and commits any mingw* related gcc
>>patches but he is not in currently.
>
>Uh, yeah.  AFAIK, you aren't listed as a package approver so it would be
>very difficult for you to approve anything.
>
>Ok, nevermind.

Did this ever get resolved?  Did Kai apply the patches?

cgf

--
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

Re: python aborts

[Jean-Pierre Flori]

Dear all,

Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :

> On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
>>On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
>>>On 7/26/2013 01:20, Christopher Faylor wrote:
>>>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>>>>> On 7/25/2013 23:14, Christopher Faylor wrote:
>>>>>>
>>>>>> I'm still a (silent) gcc maintainer so I can presumably accept this
>>>>>> patch.
>>>>>>
>>>>>> Are there outstanding patches that need attention?  If so, please
>>>>>> send URLs from the gcc-patches archive here so that I can attend to
>>>>>> them.
>>>>>>
>>>>>>
>>>>> This libgcc patch, and some minor patches at
>>>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>>>>>
>>>>> There are some others from Yaakov's gcc builds, but let's start with
>>>>> smaller patches first.
>>>> 
>>>> It will probably be a couple of days before I can give these adequate
>>>> attention.
>>>> 
>>>> Ok to submit your name as an upstream approver, JonY?
>>>> 
>>>> 
>>>I have not approved any patches for GCC, not sure if I can act as
>>>approver. Kai usually approves and commits any mingw* related gcc
>>>patches but he is not in currently.
>>
>>Uh, yeah.  AFAIK, you aren't listed as a package approver so it would be
>>very difficult for you to approve anything.
>>
>>Ok, nevermind.
> 
> Did this ever get resolved?  Did Kai apply the patches?
> 
> cgf

Any progress on this very nasty libgcc bug?
I've been struggling with random python aborts in the last past weeks, 
pointing more or less to verifyable_object_isvalid with quite unhelpful 
backtraces, when I finally found this report and a potential fix at 
http://cygwin.com/ml/cygwin/2013-07/msg00528.html.
See also http://cygwin.com/ml/cygwin/2013-08/msg00201.html.
The fix seems to do the trick for me though I cannot really rely on any 
Cygwin part linked with cyggcc_s.dll unless I recompile it.
Any plan to trigger a complete rebuild of Cygwin packages using a fixed 
GCC? :)

Best,
JP


--
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

Re: python aborts

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

On Nov  6 22:30, Jean-Pierre Flori wrote:
> Dear all,
> 
> Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
> 
> > On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
> >>On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
> >>>On 7/26/2013 01:20, Christopher Faylor wrote:
> >>>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
> >>>>> On 7/25/2013 23:14, Christopher Faylor wrote:
> >>>>>>
> >>>>>> I'm still a (silent) gcc maintainer so I can presumably accept this
> >>>>>> patch.
> >>>>>>
> >>>>>> Are there outstanding patches that need attention?  If so, please
> >>>>>> send URLs from the gcc-patches archive here so that I can attend to
> >>>>>> them.
> >>>>>>
> >>>>>>
> >>>>> This libgcc patch, and some minor patches at
> >>>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
> >>>>>
> >>>>> There are some others from Yaakov's gcc builds, but let's start with
> >>>>> smaller patches first.
> >>>> 
> >>>> It will probably be a couple of days before I can give these adequate
> >>>> attention.
> >>>> 
> >>>> Ok to submit your name as an upstream approver, JonY?
> >>>> 
> >>>> 
> >>>I have not approved any patches for GCC, not sure if I can act as
> >>>approver. Kai usually approves and commits any mingw* related gcc
> >>>patches but he is not in currently.
> >>
> >>Uh, yeah.  AFAIK, you aren't listed as a package approver so it would be
> >>very difficult for you to approve anything.
> >>
> >>Ok, nevermind.
> > 
> > Did this ever get resolved?  Did Kai apply the patches?
> > 
> > cgf
> 
> Any progress on this very nasty libgcc bug?

I pinged the upstream maintainer who probably wasn't aware of this yet.

> I've been struggling with random python aborts in the last past weeks, 
> pointing more or less to verifyable_object_isvalid with quite unhelpful 
> backtraces, when I finally found this report and a potential fix at 
> http://cygwin.com/ml/cygwin/2013-07/msg00528.html.
> See also http://cygwin.com/ml/cygwin/2013-08/msg00201.html.
> The fix seems to do the trick for me though I cannot really rely on any 
> Cygwin part linked with cyggcc_s.dll unless I recompile it.
> Any plan to trigger a complete rebuild of Cygwin packages using a fixed 
> GCC? :)

That won't happen, probably, since practically all crucial parts of the
distro are linked dynamically against libgcc.  Just providing and using
a new libgcc should be sufficient, except in rare cases.  AFAIU.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: python aborts

[Jean-Pierre Flori]

Le Thu, 07 Nov 2013 14:20:20 +0100, Corinna Vinschen a écrit :

> On Nov  6 22:30, Jean-Pierre Flori wrote:
>> Dear all,
>> 
>> Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
>> 
>> > On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
>> >>On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
>> >>>On 7/26/2013 01:20, Christopher Faylor wrote:
>> >>>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>> >>>>> On 7/25/2013 23:14, Christopher Faylor wrote:
>> >>>>>>
>> >>>>>> I'm still a (silent) gcc maintainer so I can presumably accept
>> >>>>>> this patch.
>> >>>>>>
>> >>>>>> Are there outstanding patches that need attention?  If so,
>> >>>>>> please send URLs from the gcc-patches archive here so that I can
>> >>>>>> attend to them.
>> >>>>>>
>> >>>>>>
>> >>>>> This libgcc patch, and some minor patches at
>> >>>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>> >>>>>
>> >>>>> There are some others from Yaakov's gcc builds, but let's start
>> >>>>> with smaller patches first.
>> >>>> 
>> >>>> It will probably be a couple of days before I can give these
>> >>>> adequate attention.
>> >>>> 
>> >>>> Ok to submit your name as an upstream approver, JonY?
>> >>>> 
>> >>>> 
>> >>>I have not approved any patches for GCC, not sure if I can act as
>> >>>approver. Kai usually approves and commits any mingw* related gcc
>> >>>patches but he is not in currently.
>> >>
>> >>Uh, yeah.  AFAIK, you aren't listed as a package approver so it would
>> >>be very difficult for you to approve anything.
>> >>
>> >>Ok, nevermind.
>> > 
>> > Did this ever get resolved?  Did Kai apply the patches?
>> > 
>> > cgf
>> 
>> Any progress on this very nasty libgcc bug?
> 
> I pinged the upstream maintainer who probably wasn't aware of this yet.
> 
Thanks!

> That won't happen, probably, since practically all crucial parts of the
> distro are linked dynamically against libgcc.  Just providing and using
> a new libgcc should be sufficient, except in rare cases.  AFAIU.
> 
Sure, hopefully all or most packages link to a shared cyggcc_s.dll and 
just rebuilding gcc should be enough.

My last issue was that when I built gcc, the similar library was named 
something like cyggcc_sjs.dll so the few native Cygwin packages I still 
used or linked to could still load the bad cyggcc_s.dll and make Python 
abort!

Thanks for the support,
Best,
JP


--
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

Re: python aborts

[Jean-Pierre Flori]

Le Thu, 07 Nov 2013 14:20:20 +0100, Corinna Vinschen a écrit :

> On Nov  6 22:30, Jean-Pierre Flori wrote:
>> Dear all,
>> 
>> Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
>> 
>> > On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
>> >>On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
>> >>>On 7/26/2013 01:20, Christopher Faylor wrote:
>> >>>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>> >>>>> On 7/25/2013 23:14, Christopher Faylor wrote:
>> >>>>>>
>> >>>>>> I'm still a (silent) gcc maintainer so I can presumably accept
>> >>>>>> this patch.
>> >>>>>>
>> >>>>>> Are there outstanding patches that need attention?  If so,
>> >>>>>> please send URLs from the gcc-patches archive here so that I can
>> >>>>>> attend to them.
>> >>>>>>
>> >>>>>>
>> >>>>> This libgcc patch, and some minor patches at
>> >>>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
>> >>>>>
>> >>>>> There are some others from Yaakov's gcc builds, but let's start
>> >>>>> with smaller patches first.
>> >>>> 
>> >>>> It will probably be a couple of days before I can give these
>> >>>> adequate attention.
>> >>>> 
>> >>>> Ok to submit your name as an upstream approver, JonY?
>> >>>> 
>> >>>> 
>> >>>I have not approved any patches for GCC, not sure if I can act as
>> >>>approver. Kai usually approves and commits any mingw* related gcc
>> >>>patches but he is not in currently.
>> >>
>> >>Uh, yeah.  AFAIK, you aren't listed as a package approver so it would
>> >>be very difficult for you to approve anything.
>> >>
>> >>Ok, nevermind.
>> > 
>> > Did this ever get resolved?  Did Kai apply the patches?
>> > 
>> > cgf
>> 
>> Any progress on this very nasty libgcc bug?
> 
> I pinged the upstream maintainer who probably wasn't aware of this yet.

By the way, i found:
* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680
which looks very similar.


--
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

Re: python aborts

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

On Nov  7 14:20, Corinna Vinschen wrote:
> On Nov  6 22:30, Jean-Pierre Flori wrote:
> > Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
> > > On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
> > >>On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
> > >>>On 7/26/2013 01:20, Christopher Faylor wrote:
> > >>>> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
> > >>>>> On 7/25/2013 23:14, Christopher Faylor wrote:
> > >>>>>>
> > >>>>>> I'm still a (silent) gcc maintainer so I can presumably accept this
> > >>>>>> patch.
> > >>>>>>
> > >>>>>> Are there outstanding patches that need attention?  If so, please
> > >>>>>> send URLs from the gcc-patches archive here so that I can attend to
> > >>>>>> them.
> > >>>>>>
> > >>>>>>
> > >>>>> This libgcc patch, and some minor patches at
> > >>>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00416.html.
> > >>>>>
> > >>>>> There are some others from Yaakov's gcc builds, but let's start with
> > >>>>> smaller patches first.
> > >>>> 
> > >>>> It will probably be a couple of days before I can give these adequate
> > >>>> attention.
> > >>>> 
> > >>>> Ok to submit your name as an upstream approver, JonY?
> > >>>> 
> > >>>> 
> > >>>I have not approved any patches for GCC, not sure if I can act as
> > >>>approver. Kai usually approves and commits any mingw* related gcc
> > >>>patches but he is not in currently.
> > >>
> > >>Uh, yeah.  AFAIK, you aren't listed as a package approver so it would be
> > >>very difficult for you to approve anything.
> > >>
> > >>Ok, nevermind.
> > > 
> > > Did this ever get resolved?  Did Kai apply the patches?
> > > 
> > > cgf
> > 
> > Any progress on this very nasty libgcc bug?
> 
> I pinged the upstream maintainer who probably wasn't aware of this yet.

The patche is checked in upstream.  JonY,  any chance for an updated
gcc toolchain soon?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: python aborts

[JonY]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

On 11/11/2013 20:59, Corinna Vinschen wrote:
>> I pinged the upstream maintainer who probably wasn't aware of this yet.
> 
> The patche is checked in upstream.  JonY,  any chance for an updated
> gcc toolchain soon?
> 

The 4.8.2-1 release should already contain this patch.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: python aborts

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

On Nov 11 21:02, JonY wrote:
> On 11/11/2013 20:59, Corinna Vinschen wrote:
> >> I pinged the upstream maintainer who probably wasn't aware of this yet.
> > 
> > The patche is checked in upstream.  JonY,  any chance for an updated
> > gcc toolchain soon?
> > 
> 
> The 4.8.2-1 release should already contain this patch.

Cool, thanks!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]