Guess return value

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Guess return value

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've attached a simple program to this message.
Your objective is to read it, and tell me, without compiling and
running it, the exit code of the guessreturn.exe process.

100 karma points to the person who guesses correctly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRS8cBAAoJEOs4Jb6SI2CwDF0H/R1FX82KMmSbkfdZ30vrUwAX
EgAhPG4T7bvrniwjlvkFmKnuaWqXkL+75iCJdLG1JD9cxql6IsMyPUWoS1E41i8P
yYIyBMeKJBp1fqQ7kr+fUqnO+EXeO3Y6O2c5Er4ORe2gDw5/BLFtL7lrXGTRTtel
46eb65w/2ckeCHdn4JxtCPHJci7IX+9I1nK3O7V3QD8JISNDD905wDUW6IacTaOR
6I8EIhlRMIX8/9pXkCIuIKzN9OVaA7I+oCFb7PFJAYPG88QKbG3zgY5bVgjGb9Lv
mfk7/STKsUoNNlw/+QzWmCtzyWzxJB7GnbNIG3wEURNn/9Kq+3AMAGIQf6oH3VM=
=IjZh
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

guessreturn.c (192 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
> Date: Fri, 22 Mar 2013 06:50:42 +0400
> From: LRN <[hidden email]>
>
> I've attached a simple program to this message.
> Your objective is to read it, and tell me, without compiling and
> running it, the exit code of the guessreturn.exe process.
>
> 100 karma points to the person who guesses correctly.

Exit code is 1 if libz-1.dll is not found where Windows usually looks
for DLLs, zero otherwise.

You probably meant this to be a tricky question, but if so, I don't
see the tricky part.  Maybe I didn't yet have enough coffee this
morning.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Keith Marshall
On 22 March 2013 08:33, Eli Zaretskii wrote:
> Date: Fri, 22 Mar 2013 06:50:42 +0400
> From: LRN
>
> I've attached a simple program to this message.
> Your objective is to read it, and tell me, without compiling and
> running it, the exit code of the guessreturn.exe process.
>
> 100 karma points to the person who guesses correctly.

Exit code is 1 if libz-1.dll is not found where Windows usually looks
for DLLs, zero otherwise.

You could be forgiven for thinking this, but actually, it isn't so.
 
You probably meant this to be a tricky question, but if so, I don't
see the tricky part.

More likely it's an obscure way to for the OP to tell us about his own
screw up; because he has neglected to balance his LoadLibraryA() call
with a FreeLibrary(), anything is possible.  The likely outcome is an
abort(), following an exception caught by Windows, rather than a normal
return, so the return code could be anything at all.
 
Maybe I didn't yet have enough coffee this morning.

Perhaps not :)

--
Regards,
Keith.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Gisle Vanem-2
Eli Eli Zaretskii wrote:

>> Exit code is 1 if libz-1.dll is not found where Windows usually looks
>> for DLLs, zero otherwise.

I think I agree with this.

"Keith Marshall" <[hidden email]> wrote:

> You could be forgiven for thinking this, but actually, it isn't so.
>
>
>> You probably meant this to be a tricky question, but if so, I don't
>> see the tricky part.
>
>
> More likely it's an obscure way to for the OP to tell us about his own
> screw up; because he has neglected to balance his LoadLibraryA() call
> with a FreeLibrary(), anything is possible.  

Is it? LoadLibraryA() doesn't absolutely need a FreeLibrary(). Windows
isn't that lame.
See http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
  "... The system unloads a module when its reference count reaches zero or
  when the process terminates (regardless of the reference count)."

I actually ran guessreturn.exe w/o a libz-1.dll anywhere and got a
'1' as exit-code (errorlevel). The sys-err code was 2 though; "File not found".

--gv

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Keith Marshall
On 22 March 2013 12:37, Gisle Vanem wrote:
Is it? LoadLibraryA() doesn't absolutely need a FreeLibrary(). Windows
isn't that lame.

Really?
 
See http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
  "... The system unloads a module when its reference count reaches zero or
  when the process terminates (regardless of the reference count)."

In theory, perhaps; what MSDN claims isn't always borne out in practice.
 
I actually ran guessreturn.exe w/o a libz-1.dll anywhere and got a
'1' as exit-code (errorlevel). The sys-err code was 2 though; "File not found".

Sure.  When you don't have libz-1.dll installed, this is what will
happen.  Did you bother to try *with* libz-1.dll installed?  I guess
you didn't.

I've seen this before.  Bad Things (TM) may happen, if you don't clean
up behind yourself.  Just to confirm that my memory isn't failing, I
*installed* MinGW's libz-1.dll, then built and ran LRN's code; here is
what I see, (on Windows Vista):

  This application has requested the Runtime to terminate it in an
  unusual way.  Please contact the application's support team for more
  information.

This was accompanied by a Windows pop-up, inviting me to close the
application, which it then did, *without* completing the specified
return actions; (the return code was 3).

For me, adding:

  if (h != NULL) FreeLibrary (h);

before the return statement, resolved the issue.

--
Regards,
Keith.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
> Date: Fri, 22 Mar 2013 13:17:19 +0000
> From: Keith Marshall <[hidden email]>
>
> > http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
> >   "... The system unloads a module when its reference count reaches zero or
> >   when the process terminates (regardless of the reference count)."
> >
>
> In theory, perhaps; what MSDN claims isn't always borne out in practice.

If the process is exiting, I find it hard to believe that its
resources are not freed.  You'd need to present tangible evidence to
convince me.

> When you don't have libz-1.dll installed, this is what will
> happen.  Did you bother to try *with* libz-1.dll installed?  I guess
> you didn't.

I did.  Used a slightly different name for the DLL, as my zlib is
called differently, but I did try the same program.  It returns zero
every time I run it.

> I've seen this before.  Bad Things (TM) may happen, if you don't clean
> up behind yourself.  Just to confirm that my memory isn't failing, I
> *installed* MinGW's libz-1.dll, then built and ran LRN's code; here is
> what I see, (on Windows Vista):
>
>   This application has requested the Runtime to terminate it in an
>   unusual way.  Please contact the application's support team for more
>   information.

Then the problem is specific to libz-1.dll, which I don't have, not
with LoadLibraryA in general or with FreeLibrary afterwards.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
In reply to this post by Keith Marshall
> Date: Fri, 22 Mar 2013 13:17:19 +0000
> From: Keith Marshall <[hidden email]>
>
> I've seen this before.  Bad Things (TM) may happen, if you don't clean
> up behind yourself.  Just to confirm that my memory isn't failing, I
> *installed* MinGW's libz-1.dll, then built and ran LRN's code; here is
> what I see, (on Windows Vista):
>
>   This application has requested the Runtime to terminate it in an
>   unusual way.  Please contact the application's support team for more
>   information.

I guess libz-1.dll does something in its DllMain function that must be
undone in FreeLibrary.  Bad, bad libz-1.dll!

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

lrn-2
In reply to this post by Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22.03.2013 17:17, Keith Marshall wrote:

> On 22 March 2013 12:37, Gisle Vanem wrote:
>
>> Is it? LoadLibraryA() doesn't absolutely need a FreeLibrary().
>> Windows isn't that lame.
>>
>
> Really?
>
>
>> See
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
>>
>>
"... The system unloads a module when its reference count reaches zero or
>> when the process terminates (regardless of the reference
>> count)."
>>
>
> In theory, perhaps; what MSDN claims isn't always borne out in
> practice.
MSDN is correct. If you watch the process of dll loading/unloading, in
normal circumstances W32API will call FreeLibrary() for you, if you
neglect to do it yourself.

>
>
>> I actually ran guessreturn.exe w/o a libz-1.dll anywhere and got
>> a '1' as exit-code (errorlevel). The sys-err code was 2 though;
>> "File not found".
>>
>
> Sure.  When you don't have libz-1.dll installed, this is what will
> happen.  Did you bother to try *with* libz-1.dll installed?  I
> guess you didn't.
>
> I've seen this before.  Bad Things (TM) may happen, if you don't
> clean up behind yourself.  Just to confirm that my memory isn't
> failing, I *installed* MinGW's libz-1.dll, then built and ran LRN's
> code; here is what I see, (on Windows Vista):
>
> This application has requested the Runtime to terminate it in an
> unusual way.  Please contact the application's support team for
> more information.
>
> This was accompanied by a Windows pop-up, inviting me to close the
> application, which it then did, *without* completing the specified
> return actions; (the return code was 3).
>
> For me, adding:
>
> if (h != NULL) FreeLibrary (h);
>
> before the return statement, resolved the issue.
A-a-a-nd 100 karma points are going to-o-o-o... Keith Marshall!
That said, you only found correct return code (3) after compiling and
running it yourself, so let's make it 50 karma points :)

On 22.03.2013 17:26, Eli Zaretskii wrote:
> I did.  Used a slightly different name for the DLL, as my zlib is
> called differently, but I did try the same program.  It returns
> zero every time I run it.
Try "libgcc_s_dw2-1.dll" instead of "libz-1.dll"
(libz is here just to make it more difficult to guess; naming the
culprit, libgcc_s_dw2, would have taken all the fun away)

Note that it won't work (that is, the program won't crash) if you're
using a gcc toolchain with sjlj unwinding (in which case your libgcc
will be named "libgcc_s_sjlj-1.dll").

It looks like just having libgcc loaded into memory causes the program
call __deregister_frame_info() after returning from main(). Even if
the program itself does not link to libgcc normally (via
- -shared-libgcc or -lgcc_s_dw2).
Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
tries to call that function, but crashes inside it. Maybe because
__register_frame_info() is only called by libgcc, but not by the
program (sadly, i have no way to track this reliably; it looks like
the function that actually runs has a different name, and
__deregister_frame_info/__register_frame_info are just aliases).

This means that using LoadLibrary() to dynamically load any (!) dll
that is linked directly (or indirectly) to libgcc will cause this kind
of crash, unless the program either does explicit FreeLibrary() to get
rid of libgcc before returning, or is linked to libgcc (directly or
indirectly) normally by itself (in which case LoadLibrary() does
nothing, since libgcc is already loaded and mapped into process'
address space; termination will be performed correctly). Another way
is to call ExitProcess(), which will, apparently, go around the crt
[de]initialization code and terminate the process without crashes.

Now, who would do such a thing? I mean, load a dll, and then not
unload it? Well, turns out, gstreamer does this (on purpose). Also it
is advised against unloading anything that depends on libgobject
(unless your application already links to libgobject) - it was a
design decision by glib devs to make gobject non-unloadable.

You might be wondering: why now, all of a sudden?
Well, i've been compiling my own gettext recently, and discovered [1]
that libintl doesn't really depend on libgcc, its apparent libgcc
dependency is a consequence of the package maintainer's decision to
just put -shared-libgcc into global LDFLAGS for the whole gettext.
Because of that dependency, glib and everything that had dependency on
it (the whole gtk tree and friends) linked to libgcc, indirectly, and
thus the problem went undetected (i've been building GStreamer for a
few years now).

[1]
http://mingw-users.1079350.n2.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td7580459.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRTIBAAAoJEOs4Jb6SI2Cw/CcIAMeltkt8ZnqQYff93MIjgC9B
Qx+PdYl17FR1bycjU1y4ec7tlTR2YhJPM3SZjuEz7ZetRpvSNGISkwr5UtWBp3zO
UURGs4NTMewrSrRhDOQDvuT5JRoJ/+5qs6rYKjhyrKkI2yoFGFiKwqq5fcOCiYWB
lJSZoNxMdX5wwj9HHphG2z6xR8uMGhZqIZZR007xtCRTjD0cnOFuRv6UIIRICqLy
fMTa+k34p0DkCLMHDpoP2jCG7H2KF0QkZ+ov6hd2KS/UDKAGAvL3eW9FparsqJlN
ktPXY+sUyfTD9S6eRpKie9mkCq3TydFvlEquV23EJO3oS9LR48XIkYMte9ERw08=
=p1Ir
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Erwin Waterlander
LRN schreef, Op 22-3-2013 17:01:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 22.03.2013 17:17, Keith Marshall wrote:
>> On 22 March 2013 12:37, Gisle Vanem wrote:
>>
>>> Is it? LoadLibraryA() doesn't absolutely need a FreeLibrary().
>>> Windows isn't that lame.
>>>
>> Really?
>>
>>
>>> See
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
>>>
>>>
> "... The system unloads a module when its reference count reaches zero or
>>> when the process terminates (regardless of the reference
>>> count)."
>>>
>> In theory, perhaps; what MSDN claims isn't always borne out in
>> practice.
> MSDN is correct. If you watch the process of dll loading/unloading, in
> normal circumstances W32API will call FreeLibrary() for you, if you
> neglect to do it yourself.
>
>>
>>> I actually ran guessreturn.exe w/o a libz-1.dll anywhere and got
>>> a '1' as exit-code (errorlevel). The sys-err code was 2 though;
>>> "File not found".
>>>
>> Sure.  When you don't have libz-1.dll installed, this is what will
>> happen.  Did you bother to try *with* libz-1.dll installed?  I
>> guess you didn't.
>>
>> I've seen this before.  Bad Things (TM) may happen, if you don't
>> clean up behind yourself.  Just to confirm that my memory isn't
>> failing, I *installed* MinGW's libz-1.dll, then built and ran LRN's
>> code; here is what I see, (on Windows Vista):
>>
>> This application has requested the Runtime to terminate it in an
>> unusual way.  Please contact the application's support team for
>> more information.
>>
>> This was accompanied by a Windows pop-up, inviting me to close the
>> application, which it then did, *without* completing the specified
>> return actions; (the return code was 3).
>>
>> For me, adding:
>>
>> if (h != NULL) FreeLibrary (h);
>>
>> before the return statement, resolved the issue.
> A-a-a-nd 100 karma points are going to-o-o-o... Keith Marshall!
> That said, you only found correct return code (3) after compiling and
> running it yourself, so let's make it 50 karma points :)
>
> On 22.03.2013 17:26, Eli Zaretskii wrote:
>> I did.  Used a slightly different name for the DLL, as my zlib is
>> called differently, but I did try the same program.  It returns
>> zero every time I run it.
> Try "libgcc_s_dw2-1.dll" instead of "libz-1.dll"
> (libz is here just to make it more difficult to guess; naming the
> culprit, libgcc_s_dw2, would have taken all the fun away)
>
> Note that it won't work (that is, the program won't crash) if you're
> using a gcc toolchain with sjlj unwinding (in which case your libgcc
> will be named "libgcc_s_sjlj-1.dll").
>
> It looks like just having libgcc loaded into memory causes the program
> call __deregister_frame_info() after returning from main(). Even if
> the program itself does not link to libgcc normally (via
> - -shared-libgcc or -lgcc_s_dw2).
> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
> tries to call that function, but crashes inside it. Maybe because
> __register_frame_info() is only called by libgcc, but not by the
> program (sadly, i have no way to track this reliably; it looks like
> the function that actually runs has a different name, and
> __deregister_frame_info/__register_frame_info are just aliases).
>
> This means that using LoadLibrary() to dynamically load any (!) dll
> that is linked directly (or indirectly) to libgcc will cause this kind
> of crash, unless the program either does explicit FreeLibrary() to get
> rid of libgcc before returning, or is linked to libgcc (directly or
> indirectly) normally by itself (in which case LoadLibrary() does
> nothing, since libgcc is already loaded and mapped into process'
> address space; termination will be performed correctly). Another way
> is to call ExitProcess(), which will, apparently, go around the crt
> [de]initialization code and terminate the process without crashes.
>
> Now, who would do such a thing? I mean, load a dll, and then not
> unload it? Well, turns out, gstreamer does this (on purpose). Also it
> is advised against unloading anything that depends on libgobject
> (unless your application already links to libgobject) - it was a
> design decision by glib devs to make gobject non-unloadable.
>
> You might be wondering: why now, all of a sudden?
> Well, i've been compiling my own gettext recently, and discovered [1]
> that libintl doesn't really depend on libgcc, its apparent libgcc
> dependency is a consequence of the package maintainer's decision to
> just put -shared-libgcc into global LDFLAGS for the whole gettext.
> Because of that dependency, glib and everything that had dependency on
> it (the whole gtk tree and friends) linked to libgcc, indirectly, and
> thus the problem went undetected (i've been building GStreamer for a
> few years now).
>
> [1]
> http://mingw-users.1079350.n2.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td7580459.html
>
>

In other words, we need to rebuild libintl without -shared-libgcc...

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Roumen Petrov
Erwin Waterlander wrote:

> LRN schreef, Op 22-3-2013 17:01:
>> [SNIP]
>> Try "libgcc_s_dw2-1.dll" instead of "libz-1.dll"
>> (libz is here just to make it more difficult to guess; naming the
>> culprit, libgcc_s_dw2, would have taken all the fun away)
>>
>> Note that it won't work (that is, the program won't crash) if you're
>> using a gcc toolchain with sjlj unwinding (in which case your libgcc
>> will be named "libgcc_s_sjlj-1.dll").
>>
>> It looks like just having libgcc loaded into memory causes the program
>> call __deregister_frame_info() after returning from main(). Even if
>> the program itself does not link to libgcc normally (via
>> - -shared-libgcc or -lgcc_s_dw2).
>> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
>> tries to call that function, but crashes inside it. Maybe because
>> __register_frame_info() is only called by libgcc, but not by the
>> program (sadly, i have no way to track this reliably; it looks like
>> the function that actually runs has a different name, and
>> __deregister_frame_info/__register_frame_info are just aliases).
LRN,

You save my time. I wonder why python crash on exit if load extension
modules linked to mingw.org libraries like zlib and bzip2 .
I note dependency of shared libgcc and after rebuild of all other DLLs
crash go away.

>> This means that using LoadLibrary() to dynamically load any (!) dll
>> that is linked directly (or indirectly) to libgcc will cause this kind
>> of crash, unless the program either does explicit FreeLibrary() to get
>> rid of libgcc before returning, or is linked to libgcc (directly or
>> indirectly) normally by itself (in which case LoadLibrary() does
>> nothing, since libgcc is already loaded and mapped into process'
>> address space; termination will be performed correctly). Another way
>> is to call ExitProcess(), which will, apparently, go around the crt
>> [de]initialization code and terminate the process without crashes.
I guess that most of project will reject to change code.

>> Now, who would do such a thing? I mean, load a dll, and then not
>> unload it? Well, turns out, gstreamer does this (on purpose). Also it
>> is advised against unloading anything that depends on libgobject
>> (unless your application already links to libgobject) - it was a
>> design decision by glib devs to make gobject non-unloadable.
>>
>> You might be wondering: why now, all of a sudden?
>> Well, i've been compiling my own gettext recently, and discovered [1]
>> that libintl doesn't really depend on libgcc, its apparent libgcc
>> dependency is a consequence of the package maintainer's decision to
>> just put -shared-libgcc into global LDFLAGS for the whole gettext.
>> Because of that dependency, glib and everything that had dependency on
>> it (the whole gtk tree and friends) linked to libgcc, indirectly, and
>> thus the problem went undetected (i've been building GStreamer for a
>> few years now).
>>
>> [1]
>> http://mingw-users.1079350.n2.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td7580459.html
> In other words, we need to rebuild libintl without -shared-libgcc...

May be to rebuild all libraries with 'C' code without -shared-libgcc... ?
This cannot be solution as external project may load dlls linked with
'shared gcc' and other dlls . It seems to me expected result is crash on
exit.

Another solution without to change code of third party projects ?

Regards,
Roumen


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

JonY-3
On 3/23/2013 08:41, Roumen Petrov wrote:

>>>
>>> [1]
>>> http://mingw-users.1079350.n2.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td7580459.html
>> In other words, we need to rebuild libintl without -shared-libgcc...
>
> May be to rebuild all libraries with 'C' code without -shared-libgcc... ?
> This cannot be solution as external project may load dlls linked with
> 'shared gcc' and other dlls . It seems to me expected result is crash on
> exit.
>
> Another solution without to change code of third party projects ?
What if I *want* to use the libgcc DLL? What if I want my C++ callback
exceptions to throw over C DLLs?

In other words, code properly! You don't expect things like dangling
pointers and bad reference counting to be forgivable, don't you?

Maybe you can even fix libgcc DllMain to double check before doing
anything. Maybe it's time to drop dw2 for SJLJ until SEH is available.




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

signature.asc (677 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23.03.2013 05:58, JonY wrote:
> On 3/23/2013 08:41, Roumen Petrov wrote:
>>>>
>>>> [1]
>>>> http://mingw-users.1079350.n2.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td7580459.html
>>>
>>>>
In other words, we need to rebuild libintl without -shared-libgcc...

>>
>> May be to rebuild all libraries with 'C' code without
>> -shared-libgcc... ? This cannot be solution as external project
>> may load dlls linked with 'shared gcc' and other dlls . It seems
>> to me expected result is crash on exit.
>>
>> Another solution without to change code of third party projects
>> ?
>
> What if I *want* to use the libgcc DLL? What if I want my C++
> callback exceptions to throw over C DLLs?
Exactly the point.
libgcc dependency is unnecessary in some places, but is actually
required in others (for example, all C++ DLLs are linked to libgcc).
Just dropping that dependency is not a solution.

>
> In other words, code properly! You don't expect things like
> dangling pointers and bad reference counting to be forgivable,
> don't you?
As i have said, there are software projects which do not unload
plugins. By design. Developers will be _very_ unwilling to add
unloading just because dw2 unwinding is buggy on W32.

>
> Maybe you can even fix libgcc DllMain to double check before doing
> anything.
I'm not a gcc developer.

> Maybe it's time to drop dw2 for SJLJ until SEH is available.
That's what i'm going to do.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRTR3vAAoJEOs4Jb6SI2Cw3m4IAIENFPkOlQB/gIu3SJtOD3aD
4ZUj4h+p+oQ/H3d0NezY4GI1I/eTaazKHyuVrVFrKgn2Q8kgemUVLPFU7eGL0ICp
EL2UxkK8LANjzPMKGMnQcb6NIWn+hLg3ul4cSdBtO1KoAuHWbz57vIQtfc1LCI0i
XTrbTJLl+6dPFxsKrK3tU1/8NWw48n0NzHqOqXCmfIAsN3EQq+XGiIKt0WMdfvM6
47vgTSGSLBeIW/ECmbPl72NlAgaOd699+FLqp0XxekfCIS8N7Ny0g3Dc0MGzEjJ/
ay0LHGM6GUNLxAy8YwgqYyIdGeacGWBOZPjLSzeUIFRrlwczfAlDEW/jaje/U0I=
=b11G
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
In reply to this post by lrn-2
> Date: Fri, 22 Mar 2013 20:01:04 +0400
> From: LRN <[hidden email]>
>
> It looks like just having libgcc loaded into memory causes the program
> call __deregister_frame_info() after returning from main(). Even if
> the program itself does not link to libgcc normally (via
> - -shared-libgcc or -lgcc_s_dw2).
> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
> tries to call that function, but crashes inside it. Maybe because
> __register_frame_info() is only called by libgcc, but not by the
> program (sadly, i have no way to track this reliably; it looks like
> the function that actually runs has a different name, and
> __deregister_frame_info/__register_frame_info are just aliases).

Thanks for the detailed description.

IMO, what you are describing is a clear bug in libgcc, or in a way it
is compiled as a DLL on Windows.  That bug should be reported to the
respective maintainers and fixed.

IOW, contrary to what Keith wrote, there's no general lesson to be
learned here, only that this particular DLL has a grave bug.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

NightStrike
On Fri, Mar 22, 2013 at 8:35 PM, Eli Zaretskii <[hidden email]> wrote:

>> Date: Fri, 22 Mar 2013 20:01:04 +0400
>> From: LRN <[hidden email]>
>>
>> It looks like just having libgcc loaded into memory causes the program
>> call __deregister_frame_info() after returning from main(). Even if
>> the program itself does not link to libgcc normally (via
>> - -shared-libgcc or -lgcc_s_dw2).
>> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
>> tries to call that function, but crashes inside it. Maybe because
>> __register_frame_info() is only called by libgcc, but not by the
>> program (sadly, i have no way to track this reliably; it looks like
>> the function that actually runs has a different name, and
>> __deregister_frame_info/__register_frame_info are just aliases).
>
> Thanks for the detailed description.
>
> IMO, what you are describing is a clear bug in libgcc, or in a way it
> is compiled as a DLL on Windows.  That bug should be reported to the
> respective maintainers and fixed.

You could try, but dw2 on windows is unsupported by the maintainers.
So, likely the bugs would not be fixed.  The advice has always come
down to "use sjlj" for the past number of years.

> IOW, contrary to what Keith wrote, there's no general lesson to be
> learned here, only that this particular DLL has a grave bug.

------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
In reply to this post by lrn-2
> Date: Fri, 22 Mar 2013 20:01:04 +0400
> From: LRN <[hidden email]>
>
> It looks like just having libgcc loaded into memory causes the program
> call __deregister_frame_info() after returning from main(). Even if
> the program itself does not link to libgcc normally (via
> - -shared-libgcc or -lgcc_s_dw2).
> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
> tries to call that function, but crashes inside it. Maybe because
> __register_frame_info() is only called by libgcc, but not by the
> program (sadly, i have no way to track this reliably; it looks like
> the function that actually runs has a different name, and
> __deregister_frame_info/__register_frame_info are just aliases).
>
> This means that using LoadLibrary() to dynamically load any (!) dll
> that is linked directly (or indirectly) to libgcc will cause this kind
> of crash, unless the program either does explicit FreeLibrary() to get
> rid of libgcc before returning, or is linked to libgcc (directly or
> indirectly) normally by itself (in which case LoadLibrary() does
> nothing, since libgcc is already loaded and mapped into process'
> address space; termination will be performed correctly). Another way
> is to call ExitProcess(), which will, apparently, go around the crt
> [de]initialization code and terminate the process without crashes.
>
> Now, who would do such a thing? I mean, load a dll, and then not
> unload it? Well, turns out, gstreamer does this (on purpose). Also it
> is advised against unloading anything that depends on libgobject
> (unless your application already links to libgobject) - it was a
> design decision by glib devs to make gobject non-unloadable.

This problem has hit Emacs, see

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00413.html

and the following discussions.

However, it sounds like I misunderstood the suggested solution,
because a change to Emacs, to unload all of the libraries Emacs loaded
via LoadLibrary, didn't help, see

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00420.html

and

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00422.html

The text I cite above seem to suggest unloading libgcc.  But how can
this be done, if the program didn't load that library directly in the
first place, and thus doesn't have a handle to use in FreeLibrary?

Am I missing something, or the only way to solve this is to advise
people not to use any DLL that depends on libgcc*.dll?

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.05.2013 18:06, Eli Zaretskii wrote:

>> Date: Fri, 22 Mar 2013 20:01:04 +0400
>> From: LRN <[hidden email]>
>>
>> It looks like just having libgcc loaded into memory causes the program
>> call __deregister_frame_info() after returning from main(). Even if
>> the program itself does not link to libgcc normally (via
>> - -shared-libgcc or -lgcc_s_dw2).
>> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
>> tries to call that function, but crashes inside it. Maybe because
>> __register_frame_info() is only called by libgcc, but not by the
>> program (sadly, i have no way to track this reliably; it looks like
>> the function that actually runs has a different name, and
>> __deregister_frame_info/__register_frame_info are just aliases).
>>
>> This means that using LoadLibrary() to dynamically load any (!) dll
>> that is linked directly (or indirectly) to libgcc will cause this kind
>> of crash, unless the program either does explicit FreeLibrary() to get
>> rid of libgcc before returning, or is linked to libgcc (directly or
>> indirectly) normally by itself (in which case LoadLibrary() does
>> nothing, since libgcc is already loaded and mapped into process'
>> address space; termination will be performed correctly). Another way
>> is to call ExitProcess(), which will, apparently, go around the crt
>> [de]initialization code and terminate the process without crashes.
>>
> The text I cite above seem to suggest unloading libgcc.  But how can
> this be done, if the program didn't load that library directly in the
> first place, and thus doesn't have a handle to use in FreeLibrary?

Just unload the libraries that WERE loaded directly.

The zlib example is exactly like this - the test program loads zlib,
which itself pulls libgcc dependency. If you unload zlib, it also
unloads libgcc, and everything works. This will probably work for Emacs too.

And, in case that was not clear from the Emacs thread or this thread, or
that [1] thread, libintl does not seem to need libgcc at all.

[1]
http://mingw.5.n7.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td30981.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRl5ibAAoJEOs4Jb6SI2CwOekIAJskoW7cPix9NolUnSTVlLco
++n+ymgViiNOcfCfybiNYAhnkfytT9BzOqcewBTHsVh5DJHYndkt6dTFHfdmcqk0
ktYYX2+KH41HwIZ5E0gdpjUxDGjV6EZWLXpTqYW/ShwwLvWwMzhsPGdwkY2Vq2k0
nphmWZvP5jlsINeOZtVu45mar8sS3cyMg5iJzRnLnVFFVfQMSXOyrcpwfc3mPRV+
ZWjB6cBd8gY9zp/sfXFavvcsM9Mh9rNvBv/5oA8SowCYzP8sPpjLulYBSIEE6ULI
UdH9+fSepqMw02GubxOVSpwdQMVUwDI3PTxJSY0AEUxcE+TylTKtg3Q4PKVhZ3A=
=m4yQ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
> Date: Sat, 18 May 2013 19:05:00 +0400
> From: LRN <[hidden email]>
>
> Just unload the libraries that WERE loaded directly.

That was what I did, see the patch in

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00420.html

Unfortunately, in

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00422.html

I was told the problem was not resolved by that patch, although
FreeLibrary does seem to be called as expected.  Any ideas why?

Moreover, in

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00429.html

I'm told that the abort inside libgcc happens _before_ the library
which depends on libintl (and thus on libgcc) is unloaded...

> The zlib example is exactly like this - the test program loads zlib,
> which itself pulls libgcc dependency. If you unload zlib, it also
> unloads libgcc, and everything works. This will probably work for Emacs too.

Well, unfortunately it doesn't, unless I did something stupid in the
code that unloads the DLLs.

> And, in case that was not clear from the Emacs thread or this thread, or
> that [1] thread, libintl does not seem to need libgcc at all.

I didn't say it needed, it's just that the person who was affected
used a libintl which was built with that dependency.  Replacing it
with libintl that didn't depend on libgcc solved the problem.  I just
thought I'd better avoid the problem in the first place (I think one
or two other users reported similar problems in the past).

Thanks.

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.05.2013 21:01, Eli Zaretskii wrote:
> On Sat, 18 May 2013 19:05:00 +0400 LRN wrote:
>>
>> Just unload the libraries that WERE loaded directly.
>
> That was what I did, see the patch in
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00420.html

Yeah, i've read the thread briefly. Patch has lots of emacsisms and
lispisms, so i just glossed over it.

>
> Unfortunately, in
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00422.html
>
> I was told the problem was not resolved by that patch, although
> FreeLibrary does seem to be called as expected.  Any ideas why?

Nope. The whole thing is highly esoteric.
Have you tried unloading the libraries in correct order (that is, in
reverse to the order they were loaded in)? Other than that i really have
no clue.

It might help if you get a debug build of libgcc to actually see what's
happening. I didn't do that, so i don't know, but maybe it's possible to
fix.

- --
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRl8AvAAoJEOs4Jb6SI2Cwse0IAJEncZI+tUQyFwLxZVm/otMN
yc0ANyk5FiVE1ha9dUk6Fik3x5RAMSyOcBT7zi9M0vfZwkEs9EvORML7/s9CQvjm
JiuDRd71hjSdUBJhem7AOsav3hXUH53dTDhkUobwsFKZ8w4XbpQWhpsGRPw4fDij
5PgR/xMNRu5dwN/5zyN7xPveOQ2UVMotVF+tFzxgMSwfXpDv2WDiU1KGOLD0VLT8
58dO3KGJcvIm8/sTaXblg48drkioaDDBVM/5jbWZXbIZz/aJdWSEJA05U7DtnwAL
uhuv+VG4CVCwtEIP9YmAJHLLsenjmajOM4116sxf/6EsS8w4XjrzwMfpm79zCzE=
=Tdhn
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

Eli Zaretskii
> Date: Sat, 18 May 2013 21:53:53 +0400
> From: LRN <[hidden email]>
>
> Have you tried unloading the libraries in correct order (that is, in
> reverse to the order they were loaded in)?

It's not exactly easy, but I could try, if there are no other ideas.

Do you happen to know more details than what you already wrote about
what exactly is that __deregister_frame_info call trying to do?  I
guess it's somehow related to support of exceptions across DLLs, and
that is why it is being called whenever any DLL unloads.  But what are
the details?  Those details might give a hint to why it crashes and
how to avoid that.

Also, in the case you described in the original thread, the one that
led you to this discovery, did you actually succeed in preventing the
crash by manually unloading some library, or did you just switch to a
libintl that didn't depend on libgcc?

Thanks.

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Guess return value

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.05.2013 22:18, Eli Zaretskii wrote:

>> Date: Sat, 18 May 2013 21:53:53 +0400
>> From: LRN <[hidden email]>
>>
>> Have you tried unloading the libraries in correct order (that is, in
>> reverse to the order they were loaded in)?
>
> It's not exactly easy, but I could try, if there are no other ideas.
>
> Do you happen to know more details than what you already wrote about
> what exactly is that __deregister_frame_info call trying to do?  I
> guess it's somehow related to support of exceptions across DLLs, and
> that is why it is being called whenever any DLL unloads.  But what are
> the details?  Those details might give a hint to why it crashes and
> how to avoid that.

No, sorry. You'll have to ask gcc devs.

>
> Also, in the case you described in the original thread, the one that
> led you to this discovery, did you actually succeed in preventing the
> crash by manually unloading some library, or did you just switch to a
> libintl that didn't depend on libgcc?

I switched to a toolchain built with sjlj.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRl8coAAoJEOs4Jb6SI2Cw6L8IAIjkBwMnfTKIauLLIoRzG1G0
1lVwOEKQz6cwwmEqzy0H1IIHfnFTNmk4OA9J6s5c1AZa4oc84pNZZ9JfoDSKKRXA
kjtXb2GDeuQpH1iaikClqFkJ6/4Rr0VEBMplUnlnVD6V7MgiNn2NlRX9/p0HIfTE
tTREU0/e+q2bbtdPdO5tyOcGdEGLCnpQ9R6u+I+hvW4FZkrarbWuoEPUvfunNgpF
ruZv/eSNgFpezOzUBvy/5RcVsOZLujh+2fVc7hnKH3i61F3DmN+pEzXwMlqLhB1B
Os/AT83oennKtiicieNQTdAYBovklLm69KRim3yY7ZI0p4E47SSQxwOxYwm4F24=
=/4mv
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12