public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
* libffi crashes libgobject when compiled without optimizations
@ 2013-03-09 12:40 LRN
  2013-03-16 12:56 ` Anthony Green
  0 siblings, 1 reply; 3+ messages in thread
From: LRN @ 2013-03-09 12:40 UTC (permalink / raw)
  To: libffi-discuss

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

I'm using mingw.org i386 gcc 4.7.2
When i compile libffi with -O1, everything works fine.
If i replace "-O1" with " -O0 \
 -fauto-inc-dec \
 -fcompare-elim  \
 -fcprop-registers  \
 -fdce  \
 -fdefer-pop  \
 -fdelayed-branch  \
 -fdse  \
 -fguess-branch-probability  \
 -fif-conversion2  \
 -fif-conversion  \
 -fipa-pure-const  \
 -fipa-profile  \
 -fipa-reference  \
 -fmerge-constants \
 -fsplit-wide-types  \
 -ftree-bit-ccp  \
 -ftree-builtin-call-dce  \
 -ftree-ccp  \
 -ftree-ch  \
 -ftree-copyrename  \
 -ftree-dce  \
 -ftree-dominator-opts  \
 -ftree-dse  \
 -ftree-forwprop  \
 -ftree-fre  \
 -ftree-phiprop  \
 -ftree-sra  \
 -ftree-pta  \
 -ftree-ter \
 -funit-at-a-time \
 -fomit-frame-pointer \
"
(that is, -O0 and all the optimizations that -O1 enables)
libffi crashes when libgobject is unloaded.

The crash can be reproduced with this program:

#include <windows.h>
#include <stdio.h>

int
main (int argc, char **argv)
{
  HMODULE h;

  h = LoadLibraryA ("libgobject-2.0-0.dll");
  if (h == NULL)
    printf ("Failed to loadlib: %lu\n", GetLastError ());
  else
    FreeLibrary (h);
  return 0;
}

The version of glib doesn't matter much (anything released within last
couple of years will do, i think). The version of libffi doesn't
matter either (verified for the first commit after 3.0.10 (i.e. the
one that bumped the interface)).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJROy2RAAoJEOs4Jb6SI2CwacoIAIotJT3NBP1AENCtqFDxNV0k
fz9Gs+a08KRojerz57PAlHLjytYrZR/4V1KApW4eB07dL5xPukDZKrAxm0ATW85t
wVWVu3GUznx3m8H9D6X5vMk+3NYgJtkUKylpl4O2XhZ0s+zxg3MYOJNekCE69wgF
pSvs2gkPMhZmVJBUXuuLqoVpzeLEHA7QZmyA45dX0kif77D92RReNaJgVfQwoPLb
/EWF2+OLdHflEW0rzuiZgSBWR+BjFJYJCyk5uAohh7BR71g/PNiA2dvb1c2gq3ai
GSN3PQ7jQOaG4Tc9cuxCuSKx+b0Wodf9u2RCBBPh1dzgkmkYYp0nfuOwJyIOxyI=
=BKaD
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: libffi crashes libgobject when compiled without optimizations
  2013-03-09 12:40 libffi crashes libgobject when compiled without optimizations LRN
@ 2013-03-16 12:56 ` Anthony Green
  2013-03-16 13:45   ` LRN
  0 siblings, 1 reply; 3+ messages in thread
From: Anthony Green @ 2013-03-16 12:56 UTC (permalink / raw)
  To: LRN; +Cc: libffi-discuss

On Sat, Mar 9, 2013 at 7:39 AM, LRN <lrn1986@gmail.com> wrote:
> The crash can be reproduced with this program:
>

Are you able to generate a stack trace from the crash?

Thanks,

AG

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: libffi crashes libgobject when compiled without optimizations
  2013-03-16 12:56 ` Anthony Green
@ 2013-03-16 13:45   ` LRN
  0 siblings, 0 replies; 3+ messages in thread
From: LRN @ 2013-03-16 13:45 UTC (permalink / raw)
  To: libffi-discuss

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

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

On 16.03.2013 16:56, Anthony Green wrote:
> On Sat, Mar 9, 2013 at 7:39 AM, LRN <lrn1986@gmail.com> wrote:
>> The crash can be reproduced with this program:
>> 
> 
> Are you able to generate a stack trace from the crash?
> 

F:\src\mingw\bin>gdb --args testfficrash.exe
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from F:\src\mingw\bin\testfficrash.exe...done.
(gdb) b abort
Breakpoint 1 at 0x401be8
(gdb) r
Starting program: F:\src\mingw\bin\testfficrash.exe
[New Thread 21652.0x5fa58]

Breakpoint 1, 0x6b74c9d0 in abort () from F:\src\mingw\bin\libffi-6.dll
(gdb) bt
#0  0x6b74c9d0 in abort () from F:\src\mingw\bin\libffi-6.dll
#1  0x6b74c6d6 in __deregister_frame_info_bases () from
F:\src\mingw\bin\libffi-6.dll
#2  0x6b741283 in __gcc_deregister_frame () from
F:\src\mingw\bin\libffi-6.dll
#3  0x6b741023 in __dll_exit () from F:\src\mingw\bin\libffi-6.dll
#4  0x6b7410ae in DllMainCRTStartup@12 () from
F:\src\mingw\bin\libffi-6.dll
#5  0x77a89950 in ntdll!RtlpNtMakeTemporaryKey () from
C:\Windows\system32\ntdll.dll
#6  0x6b740000 in ?? ()
#7  0x77aaacde in ntdll!TpCallbackIndependent () from
C:\Windows\system32\ntdll.dll
#8  0x6b741060 in __dll_exit () from F:\src\mingw\bin\libffi-6.dll
#9  0x00000000 in ?? ()

This is with 1.0.13-rc1
Not very useful, i know.

I've tried getting a list of symbols exported from libffi, and then
setting breakpoints on all of them, just to see what is being called.
Turns out, nothing is called, except for __deregister_frame_info_bases
(which crashes). Well, that is not precise. There are two functions
for which i can't set breakpoints, because gdb says they have the
address of 0x0. That's __register_frame_info and  __deregister_frame_info.

The libffi that is compiled with optimization does not have any weird
functions exported (just the ffi_*()).

My guess is that for -O0 libgcc is linked into libffi, which conflicts
with libgcc_s_dw2 (which is pulled by libintl, which, in turn, is
pulled by libglib, which is pulled by libgobject).

I've made another test program (attached, testcrash.c), and my
suspicions proved to be correct - it crashes. If i change the order in
which libraries are unloaded (free libffi first, then libgcc), gdb
throws some warnings around (about breakpoints) when stepping, but
otherwise program ends normally.

Why libintl links to libgcc is a question that's been bugging me for
some time now. It seems that now i have more incentives to find out
(that said, i still don't understand why libffi is linked to libgcc
when compiled with -O0).

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

iQEcBAEBAgAGBQJRRHdKAAoJEOs4Jb6SI2CwK6UH/0I2/udBwHDs9U+ueFHBD/LM
WbqCyD6w6uyV/kpORE+KzS0vBdG6nFgT0ALern3KEFlz+w2fvPkOSn+x+q8F4pW/
x9iHuz81y2D3oUb7gkAUYGoyYWTFDKHzc4olOrXkwrcUodQWBCyUKqgGHGPY4Dl2
qlUHQBPHeFuDZ4l7VDmBDR5+FmixmXXWe+kq37b76dpeXmXtQePCtMcnCwORH89z
ZPonyBPvSV3yfoLnjI5OpAKjuG05A6ptohPCTvSXi8wAzhgSpJNsWWzH/CzZWiSA
xj2Tdnqggvn1Qa6q/wVYVJivvVgYO1ONYFm9+KTYsd/3PNzR8n4tWOwCKoi+qmY=
=DLRB
-----END PGP SIGNATURE-----

[-- Attachment #2: testcrash.c --]
[-- Type: text/plain, Size: 380 bytes --]

#include <windows.h>
#include <stdio.h>

int
main (int argc, char **argv)
{
  HMODULE h;
  HMODULE h2;

  h2 = LoadLibraryA ("libgcc_s_dw2-1.dll");
  h = LoadLibraryA ("libffi-6.dll");
  if ((h == NULL) || (h2 == NULL))
  {
    printf ("Failed to loadlib: %lu\n", GetLastError ());
  }
  else
  {
    FreeLibrary (h2);
    FreeLibrary (h);
  }
  return 0;
}

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-03-16 13:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-09 12:40 libffi crashes libgobject when compiled without optimizations LRN
2013-03-16 12:56 ` Anthony Green
2013-03-16 13:45   ` LRN

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).