X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org BE3B93858409
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=towo.net
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=towo.net
Message-ID:	<953b9f57-285d-39ea-e6cf-1ad20fe60f4c@towo.net>
Date:	Fri, 25 Nov 2022 16:38:11 +0100
MIME-Version:	1.0
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
	Thunderbird/102.5.0
Subject:	Re: coredumps and/or CPU eating zombies after dlopen/fork
To:	cygwin AT cygwin DOT com
References:	<20221125132215 DOT GA24139 AT nataraj DOT eu DOT org>
From:	Thomas Wolff <towo AT towo DOT net>
In-Reply-To:	<20221125132215.GA24139@nataraj.eu.org>
X-Provags-ID:	V03:K1:+AFVM1etY3Q2fdznInS6l34mSrsNPhGZtT2tng95GCyZT15rUhE
	7QOSF71ktTv8iJFoFkHMBH8C5RCmZE/IcFSL/TOw4DEvHtIOiSfgKritoeR2aniSrN+44RR
	mBrHiEJZhijg/ubNk9b0ZHYlHyTA4JhUTq0EWa4kBX2UTxAYiuLNwe5CxlWLmIcq1Cq2dTX
	F0ZcOCdz2DHO+6r3nZtFQ==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:6yqMlRyoDc8=:zO7555V/IGGwT/jU266bea
	ns1PJX2z/k31+IkXAAUfXZjRKvo9Jud+X9ajMnhFQ3Y2gwz1J0NDm40suvRmkkbHC3EUWIfLa
	Dd09YhIuxh4JYviIYlVKNK/kI1uq6NJgh+Q8Dat5gtHBePr5Cr9lCFFkF8XdYam7oMihOAl6Z
	L7RGd84AowjoxY6F3Wl3ulbDZ7gKV/FkeqazyQkXOnJq/1UcGyFJpfVfBSUOhV5gOZB2AZTqt
	7MQA6bkka+DKm4lHkp9a0ihVxCiS6ehvrc0Mq8RKY/qKB6wpj1Nc7xkAAzWCmz6DmSVyBLIt+
	TPPGWJ5of23q4czZWTEI5DFgP6gSvqdrfCRab7I1k89LldC7Fu6hwlhd9U0auPf4j0Njt0tm4
	ATh16MU3/eXEZsnd1GDlsYzURANR9M83Id/Q6aZ5WqH3jgpVvSJA/pHabucxn/fRMMyOEMb7P
	DpATFS3qd4fsX9yKVVtOhPpgofj7x+Bps5b38LuRNKsA70cD9Dg4utzfMoyOuOIfIWZgLWiZ4
	VMc7nfdmUctcxAUwf3DyhLzdtMp6AS4y50LPxFJSaZLlIkadPZYZ+XcaUlgk6Tf6g9rtEhQEL
	ZzdBhoFP1NuuXQUN8HFi9Vi2cI58CvG6MIGH4eKTZVMkOhWH+zYrmWP/lPYVm12uW608tNEDn
	L6iY3X7HOc1iWjmqCVi7X+WQHZNp5mDeYHfcDYudjiC3+iooP8GhcBBwSOnp4T0v0ApjsxjGC
	HR7JK5+PIyOam+kZzaxYOkbAA3yckTVHN3pQjUzKI8dGmU13SVOlOHNDfQnZD5k07Gk4fS5wD
	yQrrMXV
X-Spam-Status:	No, score=-1.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_EU, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE,
	SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

Am 25/11/2022 um 14:22 schrieb Dmitry Karasik:
> URL: http://karasik.eu.org/misc/cygwin/
>
> Dear all,
>
> Here's some exception that is caused if gtk_settings_get_default() is called from a
> dll and then later fork() call is made.  The bug is not observed if the call is
> made in the main program, and neither is observed if the gtk initialization is
> done but gtk_settings_get_default() is not called.
>
> Warning: If you run ./dlload.exe without CYGWIN environment variable being set to
> dumper that will terminate the process, your system will accumulate copies of
> dlload.exe, zombie-like, which will eat CPU. strace says that these zombie
> processes repeatedly hit exceptions in endless loops. The following strace
> is repeated forever after the fork:
>
> --- Process 9108 (pid: 10439), exception c0000005 at 00000003f5baa8e0
>   1960   21097 [main] perl 10439 exception::handle: In cygwin_except_handler exception 0xC0000005 at 0x3F5BAA8E0 sp 0xFFFFC5A8
>     16   21113 [main] perl 10439 exception::handle: In cygwin_except_handler signal 11 at 0x3F5BAA8E0
>     14   21127 [main] perl 10439 try_to_debug: debugger_command 'dumper "./dlload.exe"'
>     23   21150 [main] perl 10439 break_here: break here
>     12   21162 [main] perl 10439 sig_send: sendsig 0x13C, pid 10439, signal 11, its_me 1
>     14   21176 [main] perl 10439 sig_send: wakeup 0x3F4
>     15   21191 [main] perl 10439 sig_send: Waiting for pack.wakeup 0x3F4
>     19   21210 [sig] perl 10439 sigpacket::process: returning -1
>     19   21229 [sig] perl 10439 wait_sig: signalling pack.wakeup 0x3F4
>     17   21246 [main] perl 10439 sig_send: returning 0x0 from sending signal 11
>
> I encountered this problem when I've seen random perl and python scripts hanging (as they were apparently waiting for
> forked child that never ended), and when ^C-d, I notices the accumulation of the zombie processes.
>
> The dumper's coredump doesn't show the culprit, but it does show this:
> (gdb) bt
> #0  0x00007ffa4870d744 in ntdll!ZwDelayExecution () from C:/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x00007ffa4601b03e in SleepEx () from C:/WINDOWS/System32/KERNELBASE.dll
> #2  0x000000018006205a in try_to_debug () from C:/cygwin64/bin/cygwin1.dll
> #3  0x00000001800624f6 in exception::handle(_EXCEPTION_RECORD*, void*, _CONTEXT*, _DISPATCHER_CONTEXT*) () from C:/cygwin64/bin/cygwin1.dll
> #4  0x00007ffa4871241f in ntdll!.chkstk () from C:/WINDOWS/SYSTEM32/ntdll.dll
> #5  0x00007ffa486c14a4 in ntdll!RtlRaiseException () from C:/WINDOWS/SYSTEM32/ntdll.dll
> #6  0x00007ffa48710f4e in ntdll!KiUserExceptionDispatcher () from C:/WINDOWS/SYSTEM32/ntdll.dll
> #7  0x00000003f5baa8e0 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> which seems to indicate that the exception is somewhere in cygwin runtime.  I
> haven't got around to finding out where that bug in the runtime is exactly, as
> I'd like to hear if there any smart strategies of doing that.
>
> I neither succeed to reduce the gtk_settings_get_default() to something more
> chewable (that call was actually most reduced), even though I recompiled gtk3
> locally, but its strace strangely doesn't show anything suspicious, no forks,
> no open sockets, no pipe calls, just file openings (see strace.gsettings).
>
> Kindly advise how to proceed if I can help fixing this, so far I'm a bit stuck.
I had trouble with dlopen myself, until I found it cannot be nested if a 
library called uses dlopen itself.
In my case, it helped to add flags RTLD_LAZY | RTLD_GLOBAL to dlopen.

>
> Otherwise, to reproduce, download and unpack http://karasik.eu.org/misc/cygwin/cygwin-gtk-dlopen-fork-bug.tar
> and run ./try there.
>


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -