STC for fork SEGV after dlclose

STC for fork SEGV after dlclose

[David Rothenberger]

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

The libapr1 test cases starting failing with my 64-bit package and
1.7.19-6. They worked fine with 1.7.19-5. After a little
investigation, I discovered that only the tests that involve fork()
were failing and only if the "testdso" test case ran first. That
test case checks loading and unloading DLLs.

I extracted the attached STC. It creates a simple DLL and uses
dlopen() and dlclose() on it. Then it attempts a fork().

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
fails and the test suite does not.

There's a pretty good chance that I'm doing something dumb in the
STC since I don't do this type of programming. If so, please let me
know and accept my apologies.

To run the test, just run "make". To run it without the dlclose(),
run "make test-nofail".

Regards,
David

-- 
David Rothenberger  ----  daveroth@acm.org

alimony, n:
        Having an ex you can bank on.

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

/***********************************************************************
 * This is a STC to show that fork causes a SEGV after a DLL has been loaded
 * and unloaded.
 *
 * It loads and unloads a test DLL then does a simple fork. This causes a SEGV
 * with 1.7.19-6 (although not with 1.7.19-5). If the DLL is not unloaded then
 * no SEGV occurs.
 *
 * This test was extracted from the APR test suite.
 *
 * To compile and run, just run make. To run the test without unloading the
 * DLL, run "make test-nofail".
 ***********************************************************************/
#include <string.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <dlfcn.h>
#include <errno.h>
#include <sys/wait.h>

int do_unload = 1;

void load_dso ()
{
    char dll[PATH_MAX];
    getcwd(dll, PATH_MAX);
    strcat(dll, "/mod_test.dll");

    void *os_handle = dlopen(dll, RTLD_NOW | RTLD_GLOBAL);
    if (os_handle == NULL) {
        perror("Could not open DLL");
        exit(1);
    }
    if (do_unload) {
        if (dlclose(os_handle) != 0) {
            perror("Could not close DLL");
            exit(1);
        }
    }
}

void do_fork ()
{
    pid_t pid;
    printf("Calling fork()\n"); fflush(stdout);
    if ((pid = fork()) < 0) {
        perror("fork failed");
        exit(1);
    }
    else if (pid == 0) {
        printf("In child\n"); fflush(stdout);
        exit(0);
    }
    else {
        printf("Awaiting child\n"); fflush(stdout);
        // await child
        int exit_int;
        pid_t pstatus;

        do {
            pstatus = waitpid(pid, &exit_int, WUNTRACED);
        } while (pstatus < 0 && errno == EINTR);

        printf("Child finished\n"); fflush(stdout);
    }
}

int main (int argc, const char * const * argv, const char * const *env)
{
    if (argc > 1) {
        do_unload = 0;
    }
    load_dso();
    do_fork();
    return 0;
}

[-- Attachment #3: mod_test.c --]
[-- Type: text/plain, Size: 116 bytes --]

int count_reps(int reps);

int count_reps(int reps)
{
    int i = 0;
    for (i = 0;i < reps; i++);
    return i;
}

[-- Attachment #4: Makefile --]
[-- Type: text/plain, Size: 399 bytes --]

CC=gcc
CFLAGS=-Wall
STC=stc_dso_breaks_fork
LIBS=-ldl

.PHONY: test test-nofail
test: $(STC) mod_test.dll
	./$(STC)

test-nofail: $(STC) mod_test.dll
	./$(STC) no-fail

$(STC): $(STC).c
	$(CC) $(CFLAGS) -o $@ $^ $(LIBS)

mod_test.dll: mod_test.o
	$(CC) -shared -o $@ $^

mod_test.o: mod_test.c
	$(CC) $(CFLAGS) -c $^

.PHONY: clean
clean:
	rm -f $(STC) mod_test.o mod_test.dll $(STC).exe.stackdump


[-- Attachment #5: 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: STC for fork SEGV after dlclose

[Corinna Vinschen]

On May 27 09:39, David Rothenberger wrote:
> The libapr1 test cases starting failing with my 64-bit package and
> 1.7.19-6. They worked fine with 1.7.19-5. After a little
> investigation, I discovered that only the tests that involve fork()
> were failing and only if the "testdso" test case ran first. That
> test case checks loading and unloading DLLs.

Sigh.  Thanks for the testcase.  I wonder if it wouldn't be easier
to drop libapr1 instead... ;}

> I extracted the attached STC. It creates a simple DLL and uses
> dlopen() and dlclose() on it. Then it attempts a fork().
> 
> 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?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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: STC for fork SEGV after dlclose

[David Rothenberger]

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  ----  daveroth@acm.org

"Is it just me, or does anyone else read `bible humpers' every time
someone writes `bible thumpers?'
                -- Joel M. Snyder, jms@mis.arizona.edu

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

[GOLDSTAR] Re: STC for fork SEGV after dlclose

[Corinna Vinschen]

On May 27 10:19, David Rothenberger wrote:
> 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.

Me neither.  I debugged this in the 64 bit code, and it turned out that
the 64 bit version stumbled over two bugs.  One of these bugs I
introduced only six days ago, and it affected only the 64 bit version.

The other bug was already present for quite some time and it's a generic
bug which affects 32 and 64 bit.  There's a piece of pre-fork code which
handles the loaded DLLs of a process, and there's one condition which
never worked correctly if all dlopened DLLs had already been dlclosed
before fork was called.
In theory, this should always have crashed.  Did you say in your OP that
the 32 bit 1.7.18 didn't crash, but the fork never run either in the
testcase?  That sounds weird as effect, but the bug might explain that
behaviour.

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

It's not at all ridiculous.  Thanks for providing it.

I take the opportunity to thank you for all the testcases you provided
in the last couple of months.  Your STCs have helped Cygwin a lot already!

Andrew, I'd like to have a goldstar for David for providing short, simple,
easy to reproduce testcases in plain C.  Thanks!

Other than that, I'll upload a new 32 bit snapshot and a new 64 bit
Cygwin package within the next hour or so.  Please give both of them
a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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: STC for fork SEGV after dlclose

[David Rothenberger]

On 5/27/2013 12:38 PM, Corinna Vinschen wrote:
> Other than that, I'll upload a new 32 bit snapshot and a new 64 bit
> Cygwin package within the next hour or so.  Please give both of them
> a try.

The libapr1 test suite passes for both 32 bit and 64 bit with the fixes.
Thanks!

-- 
David Rothenberger  ----  daveroth@acm.org

When it is incorrect, it is, at least *authoritatively* incorrect.
                -- Hitchiker's Guide To The Galaxy

--
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: STC for fork SEGV after dlclose

[Corinna Vinschen]

On May 28 22:14, David Rothenberger wrote:
> On 5/27/2013 12:38 PM, Corinna Vinschen wrote:
> > Other than that, I'll upload a new 32 bit snapshot and a new 64 bit
> > Cygwin package within the next hour or so.  Please give both of them
> > a try.
> 
> The libapr1 test suite passes for both 32 bit and 64 bit with the fixes.
> Thanks!

Cool!  Thanks for testing!  Also, did you check that fork now works
as expected in the dlopen/dlclose case on both platforms?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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: [GOLDSTAR] Re: STC for fork SEGV after dlclose

[Andrew Schulman]

> Andrew, I'd like to have a goldstar for David for providing short, simple,
> easy to reproduce testcases in plain C.  Thanks!

Awarded: http://cygwin.com/goldstars/#DR


--
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: STC for fork SEGV after dlclose

[David Rothenberger]

Corinna Vinschen wrote:
> On May 28 22:14, David Rothenberger wrote:
>> On 5/27/2013 12:38 PM, Corinna Vinschen wrote:
>>> Other than that, I'll upload a new 32 bit snapshot and a new 64 bit
>>> Cygwin package within the next hour or so.  Please give both of them
>>> a try.
>>
>> The libapr1 test suite passes for both 32 bit and 64 bit with the fixes.
>> Thanks!
> 
> Cool!  Thanks for testing!  Also, did you check that fork now works
> as expected in the dlopen/dlclose case on both platforms?

I hadn't (I figured you probably did) but I just retested by STC and it
passes on both platforms.

-- 
David Rothenberger                spammer? -> spam@daveroth.dyndns.org
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734

Pascal:
        A programming language named after a man who would turn over
        in his grave if he knew about it.
                -- Datamation, January 15, 1984

--
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: STC for fork SEGV after dlclose

[Corinna Vinschen]

On May 29 09:49, David Rothenberger wrote:
> Corinna Vinschen wrote:
> > On May 28 22:14, David Rothenberger wrote:
> >> On 5/27/2013 12:38 PM, Corinna Vinschen wrote:
> >>> Other than that, I'll upload a new 32 bit snapshot and a new 64 bit
> >>> Cygwin package within the next hour or so.  Please give both of them
> >>> a try.
> >>
> >> The libapr1 test suite passes for both 32 bit and 64 bit with the fixes.
> >> Thanks!
> > 
> > Cool!  Thanks for testing!  Also, did you check that fork now works
> > as expected in the dlopen/dlclose case on both platforms?
> 
> I hadn't (I figured you probably did) but I just retested by STC and it
> passes on both platforms.

Thanks for testing.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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