> there's really no reason to quote that at all Maybe, but how would I know that you did not need that?
> It means the pointer to the "signal_arrived" event object is invalid. > "signal_arrived" is used internally to notify wait functions that a > POSIX signal arrived for the process and to implement EINTR, for > instance. When you're using XSI IPC functions, the signal_arrived > handle is used in cygserver to make the IPC functions interruptible. > For that, it creates a local copy of signal_arrived using > DuplicateHandle > > For some reason the handle given to cygserver is invalid. Why, I > have no idea, and your report is missing information, so here we go > again: I can’t provide any further information at this point because I do not understand what and where to look for. But I have a slight clue that there is a race in cygserver (and that's not unusual, from my experience). There is a main process that has sems open / shm attached. That process fork()s and exec()s script every now and then. If the main process does not spawn any children, there is nothing in the log. Once it starts doing that, I see the errors coming in, and in good time correlation with the spawning schedule. The spawned processes are very short lived, merely it's a fork, then exec a shell script with just an exit statement. I suppose that when cygserver tries to read a handle, the child process (which by posix rules had inherited the shm and sems, but should have dropped them altogether at the point of exec()) is already gone, so the handle is invalid. Which is why it is the error "6" all way. How realistic does that sound? Anton Lavrentiev Contractor NIH/NLM/NCBI
