fork() crash

Markus Hoenicka markus.hoenicka@mhoenicka.de
Sat Jun 7 11:16:00 GMT 2008


Hi,

I hit a problem on Cygwin regarding fork() which is above my head. As  
the problem is fairly complex, I'm not expecting an immediate  
solution, but I'd appreciate any help to tackle this problem. And  
please excuse the lengthy description, I've done my very best to  
describe the problem as accurately as possible.

$ uname -a
CYGWIN_NT-5.1 pc51997 1.5.25(0.156/4/2) 2008-05-26 20:37 i686 Cygwin

refdbd (http://refdb.sourceforge.net) is implemented as a forking  
server. Whenever refdbd receives a client request, it forks off a  
child process. The latter handles the request and then exits.

refdbd uses libdbi (http://libdbi.sourceforge.net) as a database  
abstraction layer. libdbi is linked in as a shared object. libdbi in  
turn dlopen()s database-specific drivers. This happens in the child  
process, with the exception of a single database check, followed by a  
libdbi shutdown, which is run once in the parent process (way before  
fork()) when refdbd starts up.

Two versions of libdbi are available on my system, 0.8.2 and the  
current cvs revision (1.0-pre1). refdbd can use both versions of the  
library, and does so without any problems on other systems (FreeBSD,  
Linux etc.). I've checked refdbd on FreeBSD with valgrind without  
detecting any problems. However, combining refdbd with libdbi 1.0-pre1  
on Cygwin causes a crash of the child in fork(), whereas libdbi 0.8.2  
does not cause this problem. This is to say that apparently the code  
which executes the fork() call (refdbd) is not responsible for the  
crash, or only indirectly so.

I was not able to use gdb to debug this crash, because the child dies  
before executing even a single line of child code. I don't know of a  
way to attach to it under these circumstances.

To further investigate the problem I've added a command-line option to  
refdbd which circumvents the fork() call. That is, the client response  
is handled by the parent process itself. When skipping the fork call,  
even libdbi 1.0-pre1 no longer causes a crash. Obviously libdbi does  
not do anything which is harmful to the process per se.

If anyone would care to have a look, I've prepared the following strace logs:

refdbd-fork-libdbi-0.8.2: http://refdb.sourceforge.net/stuff/r1l08.log
refdbd-nofork-libdbi-0.8.2: http://refdb.sourceforge.net/stuff/r1noforkl08.log
refdbd-fork-libdbi-1.0-pre1: http://refdb.sourceforge.net/stuff/r1l10.log
refdbd-nofork-libdbi-1.0-pre1:  
http://refdb.sourceforge.net/stuff/r1noforkl10.log

r1l10.log is the one that crashes.

Besides, I've fiddled with simple test cases, like the one shown in  
http://wiki.winehq.org/CygwinSupport. Linking this simple app against  
libdbi does not cause any problems, even when exercising libdbi  
functions in either the parent or the child process (I can provide the  
sources of this test case if it helps).

I'm quite clueless as to where to go from here. Are there any size  
limits for forking a process? Any other clues?

regards,
Markus

-- 
Markus Hoenicka
markus.hoenicka@cats.de
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list