This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

fork() crash


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]