Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#76 closed defect (fixed)

libc: fork() failed when using dlopen()

Reported by: froloff Owned by: bird
Priority: normal Milestone: libc-0.6.2
Component: libc-backend Version: 0.6
Severity: normal Keywords: fork() dlopen DosLoadModuleEx
Cc:

Description (last modified by bird)

If process load module dynamically (dlopen) after that fork will fail.

I examine the situation a bit and divide it into 3 cases

  1. process dlopen() module then forking. Child process failed during initial fork processing.
  2. process dlopen() module, dlclose() module then forking. Parent process trapped during fork processing.
  3. process dlopen() module, dlclose() module, dlopen() module again then forking. Parent process goes endless loop in forkParValidateModules() during fork processing.

I'll send testcase and libc logs via email.

Note. I didn't find code deregistering module from modules chain - conj procedure to __libc_ForkRegisterModule().

Attachments (1)

bug_report.zip (27.9 KB) - added by froloff 14 years ago.

Download all attachments as: .zip

Change History (6)

Changed 14 years ago by froloff

comment:1 Changed 14 years ago by bird

  • Component changed from baselayout to libc-backend
  • Description modified (diff)
  • Status changed from new to assigned
  • Version set to 0.6

comment:2 Changed 14 years ago by bird

  • Description modified (diff)
  • Summary changed from fork() failed when using dlopen() to libc: fork() failed when using dlopen()

comment:3 Changed 13 years ago by bird

  • Keywords fork() dlopen DosLoadModuleEx added

I've analysed and fixed the problems.

The first problem (dlopen(); fork();) fails because of recursive execution of the initial fork buffer in forkChlDoFork(). The recursive call occurs when process the DosLoadModuleEx record for the loaded dll. The fix is simply to advance the fork stage before processing the buffer.

The second problem and third problem are cause by missing fork module deregistration when a DLL is unloaded. The fix is to implement this deregistration. This fix will require relinking of DLLs as it includes dll0.s changes.

There is a forth problem here, the sequence fork(); waitpid(); dlopen(); dlclose(); fork(); waitpid(); fails on the last waitpid. This is covered by ticket #114.

comment:4 Changed 13 years ago by bird

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [2786]) Fixed problems with fork() and module loading/unloading. Fixes #76. Fixed atexit() and on_exit() problem with callbacks in unloaded DLLs. Fixes #103.

comment:5 Changed 13 years ago by bird

(In [2787]) Fixed problems with fork() and module loading/unloading. Fixes #76. Fixed atexit() and on_exit() problem with callbacks in unloaded DLLs. Fixes #103.

Note: See TracTickets for help on using tickets.