This is the mail archive of the
mailing list for the Cygwin project.
Re: STC for fork SEGV after dlclose
- From: David Rothenberger <daveroth at acm dot org>
- To: cygwin at cygwin dot com
- Date: Mon, 27 May 2013 10:19:03 -0700
- Subject: Re: STC for fork SEGV after dlclose
- References: <51A38C2B dot 6060706 at acm dot org> <20130527170723 dot GF28463 at calimero dot vinschen dot de>
On 5/27/2013 10:07 AM, Corinna Vinschen wrote:
> On May 27 09:39, David Rothenberger wrote:
>> With the latest 32-bit snapshot (2013-05-24) this causes a
>> segfault. The same thing happens with the 64-bit release. With
>> 1.7.18, the test case hangs for quite a while, but eventually
>> finishes, except that the fork() never really happens and I get a
>> weird error code when I run it in gdb. If I skip the dlclose() call,
>> the STC runs fine.
>> It's weird, but the libapr1 test suite does not fail on 32-bit with
>> the 2013-05-24 snapshot (or with 1.7.18). I don't know why the STC
> Above you said it fails on 32 bit with 2013-05-24, too. What's the
> last working snapshot?
The STC fails with the 2013-05-24 32-bit snapshot and the 1.7.19-6
64-bit release. The full libapr1 test suite fails with the 64-bit
release if I include the testdso test cases, but succeeds if I exclude
them. For 32-bit, the full test suite passes even with the testdso test
cases. I don't understand why that is.
That is, my STC shows that a dlclose() will break subsequent fork()
calls, but that breakage doesn't occur with the full libapr1 test suite
on 32-bit for some unknown reason.
But as long as my STC isn't completely ridiculous, fixing it might fix
the 64-bit test suite.
David Rothenberger ---- email@example.com
"Is it just me, or does anyone else read `bible humpers' every time
someone writes `bible thumpers?'
-- Joel M. Snyder, firstname.lastname@example.org
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple