Re: Core dump on 32-bit Cygwin if program calls dlopen

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Houder]

>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.

> JonY, do you have a chance to have a look into this issue?

Trying to help ...

----- test program
#include <windows.h>
#include <stdio.h>

//int main (int argc, char **argv)
int main (int argc, char *argv[])
{
  HMODULE m = LoadLibrary (argv[1]);
  if (!m)
    printf ("%s: %lu\n", argv[1], GetLastError ());
  else
    printf ("Success.\n");
    // 15/07/2014: currently resulting in a crash on 32-bits only (gcc only)
  return 0;
}
-----

The test program above fails (abort) for every cyg*.dll in /usr/bin that pulls in cyggcc_s-1.dll.

(if not, the test program exits normally)

(using the same compiler and cygwin1.dll as Ken did)

H.


--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Jan Nijtmans]

2014-07-15 16:39 GMT+02:00 Corinna Vinschen:
> On Jul 15 21:55, JonY wrote:
>> On 7/15/2014 21:08, Corinna Vinschen wrote:
>> >>
>> >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
>> >
>> > JonY, do you have a chance to have a look into this issue?
>> >
>>
>> Sorry, I have been busy these few weeks, but I am well aware that there
>> is a problem with one of the libgcc changes, but has yet to investigate it.
>>
>> I believe Jon Turney has looked into it somewhat.
>
> Sounds good.  Thanks in advance.

Is this essentially the same problem as described here?

    <http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html>

Regards,
           Jan Nijtmans

--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 15 16:45, Jan Nijtmans wrote:
> 2014-07-15 16:39 GMT+02:00 Corinna Vinschen:
> > On Jul 15 21:55, JonY wrote:
> >> On 7/15/2014 21:08, Corinna Vinschen wrote:
> >> >>
> >> >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> >> >
> >> > JonY, do you have a chance to have a look into this issue?
> >> >
> >>
> >> Sorry, I have been busy these few weeks, but I am well aware that there
> >> is a problem with one of the libgcc changes, but has yet to investigate it.
> >>
> >> I believe Jon Turney has looked into it somewhat.
> >
> > Sounds good.  Thanks in advance.
> 
> Is this essentially the same problem as described here?
> 
>     <http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html>

I just read the entire thread and it looks pretty much like what we see
here.  Eli Zaretskii's analysis of the crash is very enlightening and
seems to hit the nail on its head, but unfortunately there was never any
reply from the guys maintaining the Windows parts of gcc :(


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: 819 bytes --]

Core dump on 32-bit Cygwin if program calls dlopen

[Ken Brown]

I'm getting a core dump on exit from a program that does nothing but 
call dlopen.  (But the call to dlopen succeeds.)  This happens only in 
the 32-bit case.  Here's a simple test case.

$ cat test_dlopen.c
#include <stdio.h>
#include <dlfcn.h>
int
main()
{
   const char *dllname = "cyggs-9.dll";
   void *handle;
   printf ("Trying to dlopen %s...", dllname);
   handle = dlopen (dllname, RTLD_LAZY);
   if (handle)
     {
       printf ("succeeded.\n");
       return 0;
     }
   else
     {
       printf ("failed.\n");
       return 1;
     }
}

$ gcc test_dlopen.c

$ ./a
Trying to dlopen cyggs-9.dll...succeeded.
Aborted (core dumped)

$ echo $?
134

Ken

--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 14 19:42, Ken Brown wrote:
> I'm getting a core dump on exit from a program that does nothing but call
> dlopen.  (But the call to dlopen succeeds.)  This happens only in the 32-bit
> case.  Here's a simple test case.
> 
> $ cat test_dlopen.c
> #include <stdio.h>
> #include <dlfcn.h>
> int
> main()
> {
>   const char *dllname = "cyggs-9.dll";
>   void *handle;
>   printf ("Trying to dlopen %s...", dllname);
>   handle = dlopen (dllname, RTLD_LAZY);
>   if (handle)
>     {
>       printf ("succeeded.\n");
>       return 0;
>     }
>   else
>     {
>       printf ("failed.\n");
>       return 1;
>     }
> }
> 
> $ gcc test_dlopen.c
> 
> $ ./a
> Trying to dlopen cyggs-9.dll...succeeded.
> Aborted (core dumped)

The crash occurs when calling the destructors from do_global_dtors.
The crash address points to a crash inside a destructor of libgcc
(actually cyggcc_1-1.dll) which has been pulled in by cyggs-9.dll.

What destructor in libgcc would that be?  And what is it expecting
which is apparently missing?


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Ken Brown]

On 7/15/2014 5:02 AM, Corinna Vinschen wrote:
> On Jul 14 19:42, Ken Brown wrote:
>> I'm getting a core dump on exit from a program that does nothing but call
>> dlopen.  (But the call to dlopen succeeds.)  This happens only in the 32-bit
>> case.  Here's a simple test case.
>>
>> $ cat test_dlopen.c
>> #include <stdio.h>
>> #include <dlfcn.h>
>> int
>> main()
>> {
>>    const char *dllname = "cyggs-9.dll";
>>    void *handle;
>>    printf ("Trying to dlopen %s...", dllname);
>>    handle = dlopen (dllname, RTLD_LAZY);
>>    if (handle)
>>      {
>>        printf ("succeeded.\n");
>>        return 0;
>>      }
>>    else
>>      {
>>        printf ("failed.\n");
>>        return 1;
>>      }
>> }
>>
>> $ gcc test_dlopen.c
>>
>> $ ./a
>> Trying to dlopen cyggs-9.dll...succeeded.
>> Aborted (core dumped)
>
> The crash occurs when calling the destructors from do_global_dtors.
> The crash address points to a crash inside a destructor of libgcc
> (actually cyggcc_1-1.dll) which has been pulled in by cyggs-9.dll.
>
> What destructor in libgcc would that be?  And what is it expecting
> which is apparently missing?

FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.

Ken

--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 15 07:45, Ken Brown wrote:
> On 7/15/2014 5:02 AM, Corinna Vinschen wrote:
> >On Jul 14 19:42, Ken Brown wrote:
> >>I'm getting a core dump on exit from a program that does nothing but call
> >>dlopen.  (But the call to dlopen succeeds.)  This happens only in the 32-bit
> >>case.  Here's a simple test case.
> >>
> >>$ cat test_dlopen.c
> >>#include <stdio.h>
> >>#include <dlfcn.h>
> >>int
> >>main()
> >>{
> >>   const char *dllname = "cyggs-9.dll";
> >>   void *handle;
> >>   printf ("Trying to dlopen %s...", dllname);
> >>   handle = dlopen (dllname, RTLD_LAZY);
> >>   if (handle)
> >>     {
> >>       printf ("succeeded.\n");
> >>       return 0;
> >>     }
> >>   else
> >>     {
> >>       printf ("failed.\n");
> >>       return 1;
> >>     }
> >>}
> >>
> >>$ gcc test_dlopen.c
> >>
> >>$ ./a
> >>Trying to dlopen cyggs-9.dll...succeeded.
> >>Aborted (core dumped)
> >
> >The crash occurs when calling the destructors from do_global_dtors.
> >The crash address points to a crash inside a destructor of libgcc
> >(actually cyggcc_1-1.dll) which has been pulled in by cyggs-9.dll.
> >
> >What destructor in libgcc would that be?  And what is it expecting
> >which is apparently missing?
> 
> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.

JonY, do you have a chance to have a look into this issue?


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

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

On 7/15/2014 21:08, Corinna Vinschen wrote:
>>
>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> 
> JonY, do you have a chance to have a look into this issue?
> 

Sorry, I have been busy these few weeks, but I am well aware that there
is a problem with one of the libgcc changes, but has yet to investigate it.

I believe Jon Turney has looked into it somewhat.



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

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 15 21:55, JonY wrote:
> On 7/15/2014 21:08, Corinna Vinschen wrote:
> >>
> >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> > 
> > JonY, do you have a chance to have a look into this issue?
> > 
> 
> Sorry, I have been busy these few weeks, but I am well aware that there
> is a problem with one of the libgcc changes, but has yet to investigate it.
> 
> I believe Jon Turney has looked into it somewhat.

Sounds good.  Thanks in advance.


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

Hi JonY,

On Jul 15 16:39, Corinna Vinschen wrote:
> On Jul 15 21:55, JonY wrote:
> > On 7/15/2014 21:08, Corinna Vinschen wrote:
> > >>
> > >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> > > 
> > > JonY, do you have a chance to have a look into this issue?
> > > 
> > 
> > Sorry, I have been busy these few weeks, but I am well aware that there
> > is a problem with one of the libgcc changes, but has yet to investigate it.
> > 
> > I believe Jon Turney has looked into it somewhat.
> 
> Sounds good.  Thanks in advance.

Yesterday I asked my collegues to take a stab at the issue and one of
them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
sent upstream yet.  Can we give it a try, perhaps by creating a new
libgcc DLL, please?

Thanks,
Corinna


Index: libgcc/config/i386/cygming-crtbegin.c
===================================================================
--- libgcc/config/i386/cygming-crtbegin.c	(revision 212546)
+++ libgcc/config/i386/cygming-crtbegin.c	(working copy)
@@ -99,12 +99,13 @@ static EH_FRAME_SECTION_CONST char __EH_
   = { };
 
 static struct object obj;
 
 /* Handle of libgcc's DLL reference.  */
 HANDLE hmod_libgcc;
+static void *  (*deregister_frame_fn) (const void *) = NULL;
 #endif
 
 #if TARGET_USE_JCR_SECTION
 static void *__JCR_LIST__[]
   __attribute__ ((used, section(JCR_SECTION_NAME), aligned(4)))
   = { };
@@ -130,15 +131,20 @@ __gcc_register_frame (void)
   if (h)
     {
       /* Increasing the load-count of LIBGCC_SONAME DLL.  */
       hmod_libgcc = LoadLibrary (LIBGCC_SONAME);
       register_frame_fn = (void (*) (const void *, struct object *))
 			  GetProcAddress (h, "__register_frame_info");
+      deregister_frame_fn = (void* (*) (const void *))
+	                    GetProcAddress (h, "__deregister_frame_info");
+    }
+  else
+    {
+      register_frame_fn = __register_frame_info;
+      deregister_frame_fn = __deregister_frame_info;
     }
-  else 
-    register_frame_fn = __register_frame_info;
   if (register_frame_fn)
      register_frame_fn (__EH_FRAME_BEGIN__, &obj);
 #endif
 
 #if TARGET_USE_JCR_SECTION 
   if (__JCR_LIST__[0])
@@ -158,19 +164,12 @@ __gcc_register_frame (void)
 }
 
 void
 __gcc_deregister_frame (void)
 {
 #if DWARF2_UNWIND_INFO
-  void *  (*deregister_frame_fn) (const void *);
-  HANDLE h = GetModuleHandle (LIBGCC_SONAME);
-  if (h)
-    deregister_frame_fn = (void* (*) (const void *))
-			  GetProcAddress (h, "__deregister_frame_info");
-  else 
-    deregister_frame_fn = __deregister_frame_info;
   if (deregister_frame_fn)
      deregister_frame_fn (__EH_FRAME_BEGIN__);
   if (hmod_libgcc)
     FreeLibrary (hmod_libgcc);
 #endif
 }

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

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

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

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

On 7/16/2014 15:02, Corinna Vinschen wrote:
> Hi JonY,
> 
> On Jul 15 16:39, Corinna Vinschen wrote:
>> On Jul 15 21:55, JonY wrote:
>>> On 7/15/2014 21:08, Corinna Vinschen wrote:
>>>>>
>>>>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
>>>>
>>>> JonY, do you have a chance to have a look into this issue?
>>>>
>>>
>>> Sorry, I have been busy these few weeks, but I am well aware that there
>>> is a problem with one of the libgcc changes, but has yet to investigate it.
>>>
>>> I believe Jon Turney has looked into it somewhat.
>>
>> Sounds good.  Thanks in advance.
> 
> Yesterday I asked my collegues to take a stab at the issue and one of
> them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
> sent upstream yet.  Can we give it a try, perhaps by creating a new
> libgcc DLL, please?
> 

Thanks, I'll get to it this weekend, should I make the new gcc an
experimental version? Or is just the libgcc binary required?




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

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 17 06:02, JonY wrote:
> On 7/16/2014 15:02, Corinna Vinschen wrote:
> > Hi JonY,
> > 
> > On Jul 15 16:39, Corinna Vinschen wrote:
> >> On Jul 15 21:55, JonY wrote:
> >>> On 7/15/2014 21:08, Corinna Vinschen wrote:
> >>>>>
> >>>>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> >>>>
> >>>> JonY, do you have a chance to have a look into this issue?
> >>>>
> >>>
> >>> Sorry, I have been busy these few weeks, but I am well aware that there
> >>> is a problem with one of the libgcc changes, but has yet to investigate it.
> >>>
> >>> I believe Jon Turney has looked into it somewhat.
> >>
> >> Sounds good.  Thanks in advance.
> > 
> > Yesterday I asked my collegues to take a stab at the issue and one of
> > them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
> > sent upstream yet.  Can we give it a try, perhaps by creating a new
> > libgcc DLL, please?
> > 
> 
> Thanks, I'll get to it this weekend, should I make the new gcc an
> experimental version? Or is just the libgcc binary required?

It's the libgcc DLL which gives us grief, so a new libgcc package is
sufficent, afaics.  We should check if this DLL fixes the problem and
then make it "curr" soon, I think.


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Jon TURNEY]

On 17/07/2014 08:37, Corinna Vinschen wrote:
> On Jul 17 06:02, JonY wrote:
>> On 7/16/2014 15:02, Corinna Vinschen wrote:
>>> On Jul 15 16:39, Corinna Vinschen wrote:
>>>> On Jul 15 21:55, JonY wrote:
>>>>> On 7/15/2014 21:08, Corinna Vinschen wrote:
>>>>>>>
>>>>>>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
>>>>>>
>>>>>> JonY, do you have a chance to have a look into this issue?
>>>>>
>>>>> Sorry, I have been busy these few weeks, but I am well aware that there
>>>>> is a problem with one of the libgcc changes, but has yet to investigate it.
>>>>>
>>>>> I believe Jon Turney has looked into it somewhat.

I think this is the same or a similar problem to the one I reported at 
[1].  I also created a gcc bug [2], with a suggested patch.

>>>> Sounds good.  Thanks in advance.
>>>
>>> Yesterday I asked my collegues to take a stab at the issue and one of
>>> them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
>>> sent upstream yet.  Can we give it a try, perhaps by creating a new
>>> libgcc DLL, please?
>>
>> Thanks, I'll get to it this weekend, should I make the new gcc an
>> experimental version? Or is just the libgcc binary required?
>
> It's the libgcc DLL which gives us grief, so a new libgcc package is
> sufficent, afaics.  We should check if this DLL fixes the problem and
> then make it "curr" soon, I think.

I briefly tested this other patch with my test case from the mail above, 
and it doesn't seem to help.

On 15/07/2014 15:45, Jan Nijtmans wrote:
 > Is this essentially the same problem as described here?
 >
 >      <http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html>

No, I think it is an unforeseen consequence of the patch [3] to fix that 
bug [4], which I believe is present in 4.8.3-1, introducing a new 
problem when an executable which doesn't depend on libgcc dlopen()s a 
dll which does.

[1] https://cygwin.com/ml/cygwin/2014-07/msg00083.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752
[3] https://sourceware.org/ml/cygwin/2013-07/msg00528.html
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982


--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 17 16:31, Jon TURNEY wrote:
> On 17/07/2014 08:37, Corinna Vinschen wrote:
> >On Jul 17 06:02, JonY wrote:
> >>On 7/16/2014 15:02, Corinna Vinschen wrote:
> >>>On Jul 15 16:39, Corinna Vinschen wrote:
> >>>>On Jul 15 21:55, JonY wrote:
> >>>>>On 7/15/2014 21:08, Corinna Vinschen wrote:
> >>>>>>>
> >>>>>>>FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> >>>>>>
> >>>>>>JonY, do you have a chance to have a look into this issue?
> >>>>>
> >>>>>Sorry, I have been busy these few weeks, but I am well aware that there
> >>>>>is a problem with one of the libgcc changes, but has yet to investigate it.
> >>>>>
> >>>>>I believe Jon Turney has looked into it somewhat.
> 
> I think this is the same or a similar problem to the one I reported at [1].
> I also created a gcc bug [2], with a suggested patch.
> 
> >>>>Sounds good.  Thanks in advance.
> >>>
> >>>Yesterday I asked my collegues to take a stab at the issue and one of
> >>>them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
> >>>sent upstream yet.  Can we give it a try, perhaps by creating a new
> >>>libgcc DLL, please?
> >>
> >>Thanks, I'll get to it this weekend, should I make the new gcc an
> >>experimental version? Or is just the libgcc binary required?
> >
> >It's the libgcc DLL which gives us grief, so a new libgcc package is
> >sufficent, afaics.  We should check if this DLL fixes the problem and
> >then make it "curr" soon, I think.
> 
> I briefly tested this other patch with my test case from the mail above, and
> it doesn't seem to help.
> 
> On 15/07/2014 15:45, Jan Nijtmans wrote:
> > Is this essentially the same problem as described here?
> >
> >      <http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html>
> 
> No, I think it is an unforeseen consequence of the patch [3] to fix that bug
> [4], which I believe is present in 4.8.3-1, introducing a new problem when
> an executable which doesn't depend on libgcc dlopen()s a dll which does.
> 
> [1] https://cygwin.com/ml/cygwin/2014-07/msg00083.html
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752
> [3] https://sourceware.org/ml/cygwin/2013-07/msg00528.html
> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982

I asked DJ to take another look, but I guess ultimately we need the
attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
unavailable right now, unfortunately.


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

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

On 7/18/2014 02:24, Corinna Vinschen wrote:
>>> Is this essentially the same problem as described here?
>>>
>>>      <http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html>
>>
>> No, I think it is an unforeseen consequence of the patch [3] to fix that bug
>> [4], which I believe is present in 4.8.3-1, introducing a new problem when
>> an executable which doesn't depend on libgcc dlopen()s a dll which does.
>>
>> [1] https://cygwin.com/ml/cygwin/2014-07/msg00083.html
>> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752
>> [3] https://sourceware.org/ml/cygwin/2013-07/msg00528.html
>> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982
> 
> I asked DJ to take another look, but I guess ultimately we need the
> attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
> unavailable right now, unfortunately.
> 

Looks like I haven't had much luck at poking the code to work over the
weekends.




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

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 17 20:24, Corinna Vinschen wrote:
> On Jul 17 16:31, Jon TURNEY wrote:
> > On 17/07/2014 08:37, Corinna Vinschen wrote:
> > >On Jul 17 06:02, JonY wrote:
> > >>On 7/16/2014 15:02, Corinna Vinschen wrote:
> > >>>On Jul 15 16:39, Corinna Vinschen wrote:
> > >>>>On Jul 15 21:55, JonY wrote:
> > >>>>>On 7/15/2014 21:08, Corinna Vinschen wrote:
> > >>>>>>>
> > >>>>>>>FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> > >>>>>>
> > >>>>>>JonY, do you have a chance to have a look into this issue?
> > >>>>>
> > >>>>>Sorry, I have been busy these few weeks, but I am well aware that there
> > >>>>>is a problem with one of the libgcc changes, but has yet to investigate it.
> > >>>>>
> > >>>>>I believe Jon Turney has looked into it somewhat.
> > 
> > I think this is the same or a similar problem to the one I reported at [1].
> > I also created a gcc bug [2], with a suggested patch.
> > 
> > >>>>Sounds good.  Thanks in advance.
> > >>>
> > >>>Yesterday I asked my collegues to take a stab at the issue and one of
> > >>>them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
> > >>>sent upstream yet.  Can we give it a try, perhaps by creating a new
> > >>>libgcc DLL, please?
> > >>
> > >>Thanks, I'll get to it this weekend, should I make the new gcc an
> > >>experimental version? Or is just the libgcc binary required?
> > >
> > >It's the libgcc DLL which gives us grief, so a new libgcc package is
> > >sufficent, afaics.  We should check if this DLL fixes the problem and
> > >then make it "curr" soon, I think.
> > 
> > I briefly tested this other patch with my test case from the mail above, and
> > it doesn't seem to help.
> > [...]
> I asked DJ to take another look, but I guess ultimately we need the
> attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
> unavailable right now, unfortunately.

Looks like I totally misunderstood DJ's patch.  The patch does *not*
change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
which is statically linked into the executable.

That means, to fix the issue, you don't have to replace libgcc, you
have to recompile the executable against the new crtbegin.o.

DJ still claims his patch is the correct one.  The simple testcase
dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
him.

JonY, can we get a new crtbegin.o with DJ's patch for testing?

I'm not set up to build GCC right now.  It would be cool if we could
get just this single file for testing purposes.


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Jon TURNEY]

On 22/07/2014 09:27, Corinna Vinschen wrote:
> On Jul 17 20:24, Corinna Vinschen wrote:
>> On Jul 17 16:31, Jon TURNEY wrote:
>>> On 17/07/2014 08:37, Corinna Vinschen wrote:
>>>> It's the libgcc DLL which gives us grief, so a new libgcc package is
>>>> sufficent, afaics.  We should check if this DLL fixes the problem and
>>>> then make it "curr" soon, I think.
>>>
>>> I briefly tested this other patch with my test case from the mail above, and
>>> it doesn't seem to help.
>>> [...]
>> I asked DJ to take another look, but I guess ultimately we need the
>> attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
>> unavailable right now, unfortunately.
>
> Looks like I totally misunderstood DJ's patch.  The patch does *not*
> change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
> which is statically linked into the executable.
>
> That means, to fix the issue, you don't have to replace libgcc, you
> have to recompile the executable against the new crtbegin.o.
>
> DJ still claims his patch is the correct one.  The simple testcase
> dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
> him.

Sorry, I hadn't tested it correctly.

Building my test with an updated crtbegin.o as well, my test case is fixed.

I agree this patch seems better than my suggested one, as it makes 
crtbegin do the right thing in the face of unbalanced libgcc 
load/unload, rather than attempting to balance the libgcc load/unload as 
mine does.


--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 22 13:59, Jon TURNEY wrote:
> On 22/07/2014 09:27, Corinna Vinschen wrote:
> >On Jul 17 20:24, Corinna Vinschen wrote:
> >>On Jul 17 16:31, Jon TURNEY wrote:
> >>>On 17/07/2014 08:37, Corinna Vinschen wrote:
> >>>>It's the libgcc DLL which gives us grief, so a new libgcc package is
> >>>>sufficent, afaics.  We should check if this DLL fixes the problem and
> >>>>then make it "curr" soon, I think.
> >>>
> >>>I briefly tested this other patch with my test case from the mail above, and
> >>>it doesn't seem to help.
> >>>[...]
> >>I asked DJ to take another look, but I guess ultimately we need the
> >>attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
> >>unavailable right now, unfortunately.
> >
> >Looks like I totally misunderstood DJ's patch.  The patch does *not*
> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
> >which is statically linked into the executable.
> >
> >That means, to fix the issue, you don't have to replace libgcc, you
> >have to recompile the executable against the new crtbegin.o.
> >
> >DJ still claims his patch is the correct one.  The simple testcase
> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
> >him.
> 
> Sorry, I hadn't tested it correctly.

No worries, this was my fault.  Talking about building a new libgcc
rather than building a new crtbegin.o was bound to lead everyone
off track :|

> Building my test with an updated crtbegin.o as well, my test case is fixed.

Nice!

> I agree this patch seems better than my suggested one, as it makes crtbegin
> do the right thing in the face of unbalanced libgcc load/unload, rather than
> attempting to balance the libgcc load/unload as mine does.

Ok.  I CC'ed DJ so he knows all is good, and then we probably need a
windows GCC maintainer to approve the patch I guess.  Kai?  Ping?


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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Kai Tietz]

2014-07-22 15:20 GMT+02:00 Corinna Vinschen wrote:
> On Jul 22 13:59, Jon TURNEY wrote:
>> On 22/07/2014 09:27, Corinna Vinschen wrote:
>> >On Jul 17 20:24, Corinna Vinschen wrote:
>> >>On Jul 17 16:31, Jon TURNEY wrote:
>> >>>On 17/07/2014 08:37, Corinna Vinschen wrote:
>> >>>>It's the libgcc DLL which gives us grief, so a new libgcc package is
>> >>>>sufficent, afaics.  We should check if this DLL fixes the problem and
>> >>>>then make it "curr" soon, I think.
>> >>>
>> >>>I briefly tested this other patch with my test case from the mail above, and
>> >>>it doesn't seem to help.
>> >>>[...]
>> >>I asked DJ to take another look, but I guess ultimately we need the
>> >>attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
>> >>unavailable right now, unfortunately.
>> >
>> >Looks like I totally misunderstood DJ's patch.  The patch does *not*
>> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
>> >which is statically linked into the executable.
>> >
>> >That means, to fix the issue, you don't have to replace libgcc, you
>> >have to recompile the executable against the new crtbegin.o.
>> >
>> >DJ still claims his patch is the correct one.  The simple testcase
>> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
>> >him.
>>
>> Sorry, I hadn't tested it correctly.
>
> No worries, this was my fault.  Talking about building a new libgcc
> rather than building a new crtbegin.o was bound to lead everyone
> off track :|
>
>> Building my test with an updated crtbegin.o as well, my test case is fixed.
>
> Nice!
>
>> I agree this patch seems better than my suggested one, as it makes crtbegin
>> do the right thing in the face of unbalanced libgcc load/unload, rather than
>> attempting to balance the libgcc load/unload as mine does.
>
> Ok.  I CC'ed DJ so he knows all is good, and then we probably need a
> windows GCC maintainer to approve the patch I guess.  Kai?  Ping?
>

Hi  Corinna

As I we spoke yesterday on irc, I took already a look to DJ's patch
and it is sensible.  If DJ sends patch upstream to gcc's ML, and put
me CC, I will review it asap.

Thanks,
Kai

--
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: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 24 15:08, Kai Tietz wrote:
> 2014-07-22 15:20 GMT+02:00 Corinna Vinschen wrote:
> > On Jul 22 13:59, Jon TURNEY wrote:
> >> On 22/07/2014 09:27, Corinna Vinschen wrote:
> >> >On Jul 17 20:24, Corinna Vinschen wrote:
> >> >>On Jul 17 16:31, Jon TURNEY wrote:
> >> >>>On 17/07/2014 08:37, Corinna Vinschen wrote:
> >> >>>>It's the libgcc DLL which gives us grief, so a new libgcc package is
> >> >>>>sufficent, afaics.  We should check if this DLL fixes the problem and
> >> >>>>then make it "curr" soon, I think.
> >> >>>
> >> >>>I briefly tested this other patch with my test case from the mail above, and
> >> >>>it doesn't seem to help.
> >> >>>[...]
> >> >>I asked DJ to take another look, but I guess ultimately we need the
> >> >>attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
> >> >>unavailable right now, unfortunately.
> >> >
> >> >Looks like I totally misunderstood DJ's patch.  The patch does *not*
> >> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
> >> >which is statically linked into the executable.
> >> >
> >> >That means, to fix the issue, you don't have to replace libgcc, you
> >> >have to recompile the executable against the new crtbegin.o.
> >> >
> >> >DJ still claims his patch is the correct one.  The simple testcase
> >> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
> >> >him.
> >>
> >> Sorry, I hadn't tested it correctly.
> >
> > No worries, this was my fault.  Talking about building a new libgcc
> > rather than building a new crtbegin.o was bound to lead everyone
> > off track :|
> >
> >> Building my test with an updated crtbegin.o as well, my test case is fixed.
> >
> > Nice!
> >
> >> I agree this patch seems better than my suggested one, as it makes crtbegin
> >> do the right thing in the face of unbalanced libgcc load/unload, rather than
> >> attempting to balance the libgcc load/unload as mine does.
> >
> > Ok.  I CC'ed DJ so he knows all is good, and then we probably need a
> > windows GCC maintainer to approve the patch I guess.  Kai?  Ping?
> >
> 
> Hi  Corinna
> 
> As I we spoke yesterday on irc, I took already a look to DJ's patch
> and it is sensible.  If DJ sends patch upstream to gcc's ML, and put
> me CC, I will review it asap.

Thanks a lot!

JonY, any chance we could get a gcc package with the new crtbegin.o
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: 819 bytes --]

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

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

On 7/24/2014 21:45, Corinna Vinschen wrote:
> 
> JonY, any chance we could get a gcc package with the new crtbegin.o
> soon?

Yes, I just uploaded gcc-4.8.3-2, I'll announce once it hits the mirrors.




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

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

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

On Jul 25 06:15, JonY wrote:
> On 7/24/2014 21:45, Corinna Vinschen wrote:
> > 
> > JonY, any chance we could get a gcc package with the new crtbegin.o
> > soon?
> 
> Yes, I just uploaded gcc-4.8.3-2, I'll announce once it hits the mirrors.

Thanks a lot,
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: 819 bytes --]