On Thu, 15 Jan 2004 Jeff Trawick wrote :
data race? consider http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25520
Thanks. I was able to reproduce this one.
hopefully without the fix which I subsequently committed to 2.1-dev :)
(gotta propose that one for backport I guess)
various bugs with file descriptors could lead to race conditions with data going to the wrong client... consider CAN-2003-0789, fixed in Apache 2.0.48
I am now looking at the CAN-2003-0789. I guess the following patch is to fix it:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/generators/mod_cgid.c?r1=1.157&r2=1.158&diff_format=h
However, I couldn't understand this bug, neither could I find any of previous posts to explain the bug. Can you give me some clues on how to reproduce it? Where is the data race?
not sure if you would call it a "data race"...
bug was that there were two places where we tried to close a single file descriptor... 2nd close would fail with EBADF unless some other thread had that file descriptor assigned to another file because it got a socket or file or pipe or whatever after the first close() but before the second close()... that could cause the 2nd thread to fail to write data (getting EBADF) or even worse write to some other thread's socket/pipe/file/whatever if thread 3 got that fd assigned in the mean time
"race"? sure... call it "file descriptor race" or something like that
BTW, syscall traces for any supposedly-thread-safe code should be checked very carefully for EBADF retcodes from close()... if it can get EBADF from close() passing something other than -1, then it isn't thread-safe
perhaps APR with --enable-maintainer-mode needs to blow up if APR calls close(val >= 0) and gets bad EBADF? I don't know if this would have helped CAN-2003-0789 (not sure if the apr close came after the OS close), but it might provide some help in the future, or at least some comfort knowing that it hasn't blown up.
