This is the mail archive of the cygwin@sourceware.cygnus.com 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]

Re: fork + dlls


"Fifer, Eric" <EFifer@sanwaint.com> writes:
> 
> I'm having a problem that when I manually load a dll with dlopen,
> that after the fork the dll is not accessible from the child process.
> 
> There was an old thread on this topic that suggested that this should
> work, but with the following code the child fails when calling dll1_func:
> 
> forkbug1.c:

Thanks for the compact testcase!

This has been a bug since day one, and one that needs a bit of redesign
of the code in winsup/dll_init.cc to do it right. The current code there
is quite complex, and overly so in some cases, and someone who knows more 
about it needs to take a look. 

Essentially, this is what that needs to be done in dlopen:
  
  - load the library using LoadLibrary (done)
  - record the handle/name pair using a technique similar to what's done
    in DllList::recordDll, but without the _initCalled bit to avoid
    infinite loop.

after fork, the DllLoadedIterator will do the right thing and copy it into
the child's process space.

dlclose needs to take it off the list so that it doesn't get copied. Looks
like someone did start doing it by calling DllList::currentDlOpenedLib, but
it was unfinished, and in fact, buggy.

(chris, if you just comment out the call to currentDlOpenedLib in dlopen,
that bug we talked about will go away. however, it'll still be unavailable
after a fork).

I have a hack that will make it work, but it's not the correct way to do
it. I'll take this up in cygwin-developers list.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


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