Shared library behavior in forked (not forking) processes

[cavaliercoder]

Issue #15538 established that a process which has loaded a Go shared library (and therefore, instantiated the Go runtime) cannot call fork() and make use of Go code in child processes.

I tested the inverse; forking multiple processes and then loading a Go library in each child via dlopen(). I expected this to work but unfortunately I hit similar behaviors to the other issue; semaphore errors, file descriptor errors, dead locks, etc.

To reproduce the issue:

• write a Go shared library which exports symbols to C and calls multithreaded functions like net.Dial
• write a C program which forks more than once
• in each child process, call dlopen to load the Go library
• call a multithreaded function in the Go library

The first child to make use of the Go library should succeed. Subsequent calls should behave undefined. Symptoms differ between OS.

Confirmed on Go v1.5.4 and v1.6.2 on Red Hat 7.2 and OS X 10.11.4 x86_64.

Example code to reproduce this issue is available on gist:https://gist.github.com/cavaliercoder/68bb2ee0d673cb3d585199fe189fb171

[minux]

I think there is a problem in cbin.c:

// fork
for (i = 0; i < 5; i++) {
    if (0 < (child = fork())) {
        waitpid(child, NULL, 0);
    } else if (0 == child) {
        // load lib and func symbol
        void            *golib = NULL;
        golib_func      f;

        printf("Start child %i (%i)\n", i, getpid());
        if (NULL != (golib = dlopen("./golib.so", RTLD_NOW))) {
            if (NULL != (f = dlsym(golib, "TestNetDial"))) {
                (*f)();
            } else {
                printf("%s\n", dlerror());
            }

            dlclose(golib);  // <<<<=== THIS LINE
        } else {
            printf("%s\n", dlerror());
        }
    } else {
        printf("failed fork: 0x%0X\n", errno);
    }
}

Note that the child processes don't exit after calling the Go function
(Go shared library can't be dlclosed, but that's another issue.)

so, after the dlclose, the child will go back to the for loop, and fork,
which will lead to bad things.

The fix is to change dlclose(golib) to exit(0) and the program will
work as intended.

I will close the issue, please feel free reopen if you disagree about
the analysis.

[cavaliercoder]

Hi @minux, thanks for the analysis. You were correct. Apologies for the distraction.
I was also running each fork in series instead of parallel thanks to the waitpid inside the loop.

I've updated the Gist linked above with the working code as described.