Opened 14 years ago

Closed 10 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:
Cc:

Description

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 14 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 14 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 14 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 14 years ago by dmik

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

comment:5 Changed 13 years ago by bird

Component: libclibc-backend
Milestone: libc-0.6.4

comment:6 Changed 13 years ago by bird

Status: newassigned

comment:7 Changed 12 years ago by bird

Milestone: libc-0.6.5libc-0.6.6

comment:8 Changed 10 years ago by Yuri Dario

Milestone: libc-0.6.6

comment:9 Changed 10 years ago by bird

Resolution: wontfix
Status: assignedclosed

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.