Re: dietlibc (0.31), fork and pthreads

Tim MÃŒnchen ha scritto:
> Hi,
> 
> 
> I stumbled across a strange behaviour when linking pthreads in a program that 
> forks and creates a pipe. It looks like after fork()ing, in the child 
> process, stdin is closed - but *only* when pthreads is linked in (it doesn't 
> even need to be actually used). I don't know if this is a dietlibc thing, but 
> maybe someone of you has an idea... 
> 
> (by the way, I wanted to check if in 0.32 the behaviour is the same, but 0.32 
> segfaults on my machine; this, however, is another problem I'd like not to 
> mix in this mail :-) so, if the behaviour I described here is fixed in 0.32 
> or trunk, please tell me so, then I'll try and get it running - maybe with 
> help of this list as well.)
> 
> Back to my current issue.
> 
> The little test case I use:
> ------------------------------------------------------------------------
> $ cat forktest.c
> #include <stdio.h>
> #include <sys/types.h>
> 
> int main(int argc, char **argv) {
>         int fds[2] = {0};
>         pipe(fds);
>         printf("%s:%d [%s] - pipe() returned %d,%d\n", __FILE__,
> 		__LINE__, "before fork", fds[0], fds[1]);
>         close(fds[0]);
>         close(fds[1]);
> 
>         pid_t pid = fork();
>         if (pid == 0) {
>                 pipe(fds);
>                 printf("%s:%d [%s] - pipe() returned %d,%d\n", __FILE__,
> 			__LINE__, "child", fds[0], fds[1]);
>                 close(fds[0]);
>                 close(fds[1]);
>         }
>         else {
>                 pipe(fds);
>                 printf("%s:%d [%s] - pipe() returned %d,%d\n", __FILE__,
> 			__LINE__, "parent", fds[0], fds[1]);
>                 close(fds[0]);
>                 close(fds[1]);
> 
>                 waitpid(pid);
>         }
> 
>         return 0;
> }
> ------------------------------------------------------------------------
> 
> Now I'm compiling this test-program with gcc, against glibc, dietlibc, both 
> with linking pthreads in and without. Note, again, that nothing of pthreads 
> is actually used in that test program...
> 
> $ gcc -o forktest_gcc_pure forktest.c
> $ gcc -o forktest_gcc_pthreads forktest.c -lpthread
> $ diet gcc -o forktest_diet_pure forktest.c
> $ diet gcc -o forktest_diet_pthreads forktest.c -lpthread
> 
> Now, when running those test programs, I'd expect the pipes to use fds 3 and 4 
> (because pipe() uses the lowest two free fds). Surprisingly, the output looks 
> like this:
> 
> $ ./forktest_gcc_pure
> forktest.c:8 [before fork] - pipe() returned 3,4
> forktest.c:15 [child] - pipe() returned 3,4
> forktest.c:21 [parent] - pipe() returned 3,4
> 
> $ ./forktest_gcc_pthreads
> forktest.c:8 [before fork] - pipe() returned 3,4
> forktest.c:15 [child] - pipe() returned 3,4
> forktest.c:21 [parent] - pipe() returned 3,4
> 
> $ ./forktest_diet_pure
> forktest.c:8 [before fork] - pipe() returned 3,4
> forktest.c:15 [child] - pipe() returned 3,4
> forktest.c:21 [parent] - pipe() returned 3,4
> 
> $ ./forktest_diet_pthreads
> forktest.c:8 [before fork] - pipe() returned 3,4
> forktest.c:15 [child] - pipe() returned 0,3
> forktest.c:21 [parent] - pipe() returned 3,4
> 
> 
> ...so only the combination -lpthreads and dietlibc causes fd 0 to be used by 
> the pipe, only in the child after forking. fd 0 seems to be somehow closed by 
> fork()...
> 
> 
> Has someone an idea?
> 
> 
> Thanks,
>   Tim
> 
> 
Get used to compile with all warnings enabled, it helps.
If you do it, you'll be tempted to #include the missing headers, and the 
program won't compile because of "waitpid(pid)"; fixing it solved the 
problem on my machine.

Except that I still don't know why it would print "0": my only guess 
(the missing "int *" param overwriting something) doesn't really explain 
it, so if anybody knows better, I'm curious to hear the explanation.
(thanks anyone)

lb