DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=Bmbi+L
	ot5r0DJkI4O4EF9tG5IWDyfQoWrhdgNOCMUwpUNidBD+LiwJIBienoEvoVROF681
	KBCGg5aRLPnbOlMh6rxm5GkHs9rIyRRxNJEL5/EOUKKeMsbLoWNGIFPYkXBIWbpx
	BNB9CLizmM0u4BmIaN+Pen2XA4xpakCs0fsMc=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <53BAA770.7070005@dronecode.org.uk>
Date: Mon, 07 Jul 2014 14:58:08 +0100
From: Jon TURNEY <jon DOT turney AT dronecode DOT org DOT uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: abort during exit() with a dynamically loaded C++ library
References: <53A084E7 DOT 9010807 AT dronecode DOT org DOT uk>
In-Reply-To: <53A084E7.9010807@dronecode.org.uk>
Content-Type: multipart/mixed; boundary="------------070102050805060806020100"

--------------070102050805060806020100
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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 AT gcc DOT gnu DOT org/msg68286.html


--------------070102050805060806020100
Content-Type: text/plain; charset=windows-1252;
 name="cygming-crtbegin.c.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="cygming-crtbegin.c.patch"

LS0tIGN5Z21pbmctY3J0YmVnaW4uYy5iYWsJMjAxNC0wNy0wMyAxNjo0MTo0
My4xMTY2MDAwMDAgKzAxMDAKKysrIGN5Z21pbmctY3J0YmVnaW4uYwkyMDE0
LTA3LTAzIDE4OjM5OjA3LjQzNjgwMDAwMCArMDEwMApAQCAtOTksOCArOTks
MjEgQEAKIAogICBpZiAoaCkKICAgICB7Ci0gICAgICAvKiBJbmNyZWFzaW5n
IHRoZSBsb2FkLWNvdW50IG9mIExJQkdDQ19TT05BTUUgRExMLiAgKi8KLSAg
ICAgIGhtb2RfbGliZ2NjID0gTG9hZExpYnJhcnkgKExJQkdDQ19TT05BTUUp
OworICAgICAgLyoKKyAgICAgICAgIEluY3JlYXNlIHRoZSBsb2FkLWNvdW50
IG9mIHRoZSBMSUJHQ0NfU09OQU1FIERMTCBieSBvbmUsIHNvIHRoYXQgaXQg
cmVtYWlucworICAgICAgICAgbG9hZGVkIGFzIGxvbmcgYXMgdGhpcyBtb2R1
bGUgaXMsIHNvIHRoYXQgX19nY2NfZGVyZWdpc3Rlcl9mcmFtZSgpIHdpbGwg
Y2FsbAorICAgICAgICAgX19kZXJlZ2lzdGVyX2ZyYW1lX2luZm8oKSBpbiB0
aGF0IERMTCwgdG8gbWF0Y2ggdGhlIHJlZ2lzdGVyX2ZyYW1lX2luZm8oKQor
ICAgICAgICAgd2UgZG8gbm93LgorCisgICAgICAgICBVbmxlc3MgdGhpcyAq
aXMqIExJQkdDQ19TT05BTUUgRExMLCB3aGVyZSBpbmNyZWFzaW5nIG91ciBv
d24gbG9hZC1jb3VudCB3b3VsZAorICAgICAgICAgbWFrZSB1cyBzZWxmLXBp
bm5pbmcuCisgICAgICAqLworICAgICAgSE1PRFVMRSBobW9kX3RoaXMgPSAw
OworICAgICAgR2V0TW9kdWxlSGFuZGxlRXggKEdFVF9NT0RVTEVfSEFORExF
X0VYX0ZMQUdfRlJPTV9BRERSRVNTIHwgR0VUX01PRFVMRV9IQU5ETEVfRVhf
RkxBR19VTkNIQU5HRURfUkVGQ09VTlQsCisJIChMUENUU1RSKV9fZ2NjX3Jl
Z2lzdGVyX2ZyYW1lLCAmaG1vZF90aGlzKTsKKyAgICAgIGlmIChobW9kX3Ro
aXMgIT0gaCkKKyAgICAgICAgICBobW9kX2xpYmdjYyA9IExvYWRMaWJyYXJ5
IChMSUJHQ0NfU09OQU1FKTsKKwogICAgICAgcmVnaXN0ZXJfZnJhbWVfZm4g
PSAodm9pZCAoKikgKGNvbnN0IHZvaWQgKiwgc3RydWN0IG9iamVjdCAqKSkK
IAkJCSAgR2V0UHJvY0FkZHJlc3MgKGgsICJfX3JlZ2lzdGVyX2ZyYW1lX2lu
Zm8iKTsKICAgICB9Cg==


--------------070102050805060806020100
Content-Type: text/plain; charset=us-ascii

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