Opened 10 years ago

Closed 6 years ago

#217 closed defect (wontfix)

LIBC Error: Couldn't register process in shared memory!

Reported by: dmik Owned by: bird
Priority: normal Milestone:
Component: libc-backend Version: 0.6
Severity: normal Keywords:


This happens with the current trunk (064x) under the following conditions:

  1. A process using LIBC063.DLL is up and running so that the __LIBC_SPMHEADER structure is already created in the shared memory.
  1. A process using LIBC064x.DLL is getting started which results in the above error message.

Debugging LIBC064x.DLL shows that the message appears because the DosOpenEventSem?() here returns ERROR_INVALID_HANDLE on a handle which looks OK here (0x800103C or like that).

Note that spmInit() in LIBC063.DLL doesn't do DosOpenEventSem?() (which is not fully clear since this call is kind of required to make use of the semaphore from another process) and therefore if the second process is LIBC063.DLL-based, it starts fine.

Change History (9)

comment:1 Changed 10 years ago by dmik

Found another interesting detail. ERROR_INVALID_HANDLE only happens if the process that first loads LIBC063.DLL is started via the RUN= statement of CONFIG.SYS. If I kill that process and then start it again (e.g. as a PMSHELL descendant), everything works fine meaning that the LIBC063.DLL's semaphore gets successfully opened by LIBC064x.DLL.

To me, it looks like DC_SEM_SHARED in DosCreateEventSem?() is ignored for processes started from CONFIG.SYS.

comment:2 Changed 10 years ago by dmik

OTOH, if I replace LIBC063.DLL CSD3 with the one that is a forwarder to LIBC064x.DLL, DosOpenEventSem?() succeeds even if DosCreateEventSem?() is called from the RUN= process. The obvious difference to the previous case is that here we have the same DLL that both creates and opens the semaphore while in the case which fails there are two different DLLs (but operating on the same shared memory block of course).

comment:3 Changed 10 years ago by dmik

Just for the record, moving the process from RUN= to the startup folder (and changing LIBC063.DLL back to CSD3 level) solves the problem too which is just another evidence of it being connected to RUN= somehow.

comment:4 Changed 10 years ago by dmik

Please replace 'trunk' with '/branches/libc-0.6' above.

comment:5 Changed 9 years ago by bird

  • Component changed from libc to libc-backend
  • Milestone set to libc-0.6.4

comment:6 Changed 9 years ago by bird

  • Status changed from new to assigned

comment:7 Changed 8 years ago by bird

  • Milestone changed from libc-0.6.5 to libc-0.6.6

comment:8 Changed 6 years ago by ydario

  • Milestone libc-0.6.6 deleted

comment:9 Changed 6 years ago by bird

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

Not going to spend time digging into this, the workaround seems good enough for me (use the forwarder DLL).

Note: See TracTickets for help on using tickets.