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
[EMAIL PROTECTED]
(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/