abort during exit() with a dynamically loaded C++ library

abort during exit() with a dynamically loaded C++ library

[Jon TURNEY]

I think I have found a problem when building programs using the latest 
mesa library, where abort is being called during exit()

This seems to be x86 specific, and looks like it is somehow related to 
having a C++ library dynamically loaded by a C program.

I think I have reduced it to the following test case:

test.c:

#include <assert.h>
#include <dlfcn.h>

int main()
{
    void *h = dlopen("dllib.dll", 0);
    assert(h);
    dlclose(h);
}

dllib.c:

#include <fstream>

std::fstream instance;

Makefile:

all:
         g++ -g -O0 -c dllib.cc
         g++ -g -O0 -shared -o dllib.dll dllib.o
         gcc -g -O0 -o test.exe test.c
         ./test


Running under gdb shows gcc_abort() in __deregister_frame_info_bases() 
is being hit

$ gdb test
[...]
Program received signal SIGABRT, Aborted.
0x0028da18 in ?? ()
(gdb) bt
#0  0x0028da18 in ?? ()
#1  0x74f912cc in WriteFile () from 
/cygdrive/c/Windows/syswow64/kernel32.dll
#2  0x610da70c in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 
(p=p@entry=0x60fd0000, si=..., tls=tls@entry=0x0)
     at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/sigproc.cc:638
#3  0x610d7dbc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd0000, si=...)
     at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:248
#4  0x610d8286 in kill0 (pid=pid@entry=5044, si=...) at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:299
#5  0x610d8452 in kill (sig=sig@entry=6, pid=5044) at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:308
#6  raise (sig=sig@entry=6) at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:284
#7  0x610d86f3 in abort () at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:371
#8  0x699134d1 in __deregister_frame_info_bases (begin=0x404038 
<__EH_FRAME_BEGIN__>)
     at /usr/src/debug/gcc-4.8.3-1/libgcc/unwind-dw2-fde.c:216
#9  0x00401182 in __gcc_deregister_frame ()
#10 0x61006466 in do_global_dtors () at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:62
#11 0x61159aba in __call_exitprocs (code=code@entry=0, d=d@entry=0x0)
     at 
/usr/src/debug/cygwin-1.7.30-1/newlib/libc/stdlib/__call_atexit.c:118
#12 0x611305d8 in exit (code=0) at 
/usr/src/debug/cygwin-1.7.30-1/newlib/libc/stdlib/exit.c:66
#13 0x61006b39 in cygwin_exit (n=0) at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:1248
#14 0x61008041 in cygwin_exit_return () at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:1041
#15 0x61005e84 in _cygtls::call2(unsigned long (*)(void*, void*), void*, 
void*)@16 (this=<optimized out>,
     func=func@entry=0x610071d0 <dll_crt0_1(void*)>, arg=arg@entry=0x0, 
buf=buf@entry=0x28cd84)
     at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/cygtls.cc:100
#16 0x61005ff6 in _cygtls::call (func=func@entry=0x610071d0 
<dll_crt0_1(void*)>, arg=arg@entry=0x0)
     at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/cygtls.cc:30
#17 0x61006f54 in _dll_crt0@0 () at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:1098
#18 0x00401222 in cygwin_crt0 (f=0x4011a0 <main>) at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/lib/cygwin_crt0.c:22
#19 0x00401015 in mainCRTStartup () at 
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/crt0.c:29

--
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: abort during exit() with a dynamically loaded C++ library

[Jon TURNEY]

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

On 17/06/2014 19:11, Jon TURNEY wrote:
> I think I have found a problem when building programs using the latest
> mesa library, where abort is being called during exit()
>
> This seems to be x86 specific, and looks like it is somehow related to
> having a C++ library dynamically loaded by a C program.
>
> I think I have reduced it to the following test case:

So, this seems to be related to this patch [1], to fix a different abort 
during __gcc_deregister_frame()

[1] https://sourceware.org/ml/cygwin/2013-07/msg00528.html

Since this code is baked into libgcc itself, that patch has the 
side-effect of making libgcc pin itself in memory.

I can't really tell from what's written there if that was deliberate or 
not, but it seems that it introduces a different problem when the 
executable doesn't have a dependency on libgcc.

> test.c:
>
> #include <assert.h>
> #include <dlfcn.h>
>
> int main()
> {
>     void *h = dlopen("dllib.dll", 0);
>     assert(h);
>     dlclose(h);

The problem can be worked around by adding code to force libgcc to get 
unloaded here, which seems to support this theory, e.g.

+#define LIBGCC_SONAME "cyggcc_s-1.dll"
+   HANDLE hmod_libgcc = GetModuleHandle(LIBGCC_SONAME);
+   FreeLibrary(hmod_libgcc);

> }

Attached is a patch which modifies __gcc_register_frame() to avoid it 
pinning itself in memory.

Alternatively, as one of the emails in the linked thread says [2], the 
assert in __deregister_frame_info_bases() itself could be removed.

[2] http://www.mail-archive.com/gcc@gcc.gnu.org/msg68286.html


[-- Attachment #2: cygming-crtbegin.c.patch --]
[-- Type: text/plain, Size: 1093 bytes --]

--- cygming-crtbegin.c.bak	2014-07-03 16:41:43.116600000 +0100
+++ cygming-crtbegin.c	2014-07-03 18:39:07.436800000 +0100
@@ -99,8 +99,21 @@
 
   if (h)
     {
-      /* Increasing the load-count of LIBGCC_SONAME DLL.  */
-      hmod_libgcc = LoadLibrary (LIBGCC_SONAME);
+      /*
+         Increase the load-count of the LIBGCC_SONAME DLL by one, so that it remains
+         loaded as long as this module is, so that __gcc_deregister_frame() will call
+         __deregister_frame_info() in that DLL, to match the register_frame_info()
+         we do now.
+
+         Unless this *is* LIBGCC_SONAME DLL, where increasing our own load-count would
+         make us self-pinning.
+      */
+      HMODULE hmod_this = 0;
+      GetModuleHandleEx (GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
+	 (LPCTSTR)__gcc_register_frame, &hmod_this);
+      if (hmod_this != h)
+          hmod_libgcc = LoadLibrary (LIBGCC_SONAME);
+
       register_frame_fn = (void (*) (const void *, struct object *))
 			  GetProcAddress (h, "__register_frame_info");
     }

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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: abort during exit() with a dynamically loaded C++ library

[jojelino]

On 2014-07-07 PM 10:58, Jon TURNEY wrote:
> On 17/06/2014 19:11, Jon TURNEY wrote:
>> I think I have found a problem when building programs using the latest
>> mesa library, where abort is being called during exit()

The main concern of this crash is the order mismatch between loading and 
unloading dynamic library. It seems that either crtbegin or crtend code 
of i386 libgcc has some pitfall. The mismatch always occurs when main() 
didn't statically link to libgcc.

If my memory serves me correctly, static version of deregister_frame_fn 
is set to wrong address (see cygming-crtbegin.c) by unknown fallacy of 
gnu-ld linker. That is, Object file seems okay, But generated dll breaks 
offset argument resulting in invalid offset operand of memory 
references, although Kai Tietz said in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 that It had been fixed.

Until the fallacy of gnu-ld is being resolved by someone that has plenty 
of time or someone have workaround against the fallacy of 
ever-not-warranted linker, I'll suggest you to just call 
dlopen("cyggcc_s-1") before dlopen'ing any DLL that has dynamic linkage 
to libgcc. It would be okay for workarounding the problem.
-- 
Regards.


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