Check? If you dont have source code then maybe in debugger, don’t know…
(Using 6.2.1 for the tests…)
About that sem_open() call:
You are using O_CREAT in both of the processes, i have tested that the second sem_open() call doesn’t fail buf also doesn’t do what is supposed to do. The semaphore is opened but the “counter” remains from previous calls, it doesnt reset to value specified in the sem_open() call. Maybe the semaphore is now in an undefined state. However even if i make the semaphore block in both processes, it only become REPLY blocked on mqueue process as expected.
(note: you have to use the sem_close() to close the semaphore created using sem_open(), calling sem_init()/sem_destroy() on a semaphore created using sem_open() may result in undefined behaviour)
In pidin output the “STATE” and “Blocked” columns in this case means that the process is blocked on semaphore which is mapped in its virtual adress space on adress 0x05689cc0.
sem_init(&sem, 0, 0);
printf("semaphore %p\n", &sem);
prints “semaphore 8047b4c” and pidin reports “SEM 8047b4c” in my case
sem = sem_open("test", O_CREAT, S_IRWXG|S_IRWXO|S_IRWXU, 0);
(did i mention already that calling something “test” may in some cases cause very unrealiable results?)
pidin now reports “REPLY 12292” where 12292 is the PID (on my system) of the mqueue process (message queue and named semaphore manager)
(which reminds me to ask you if mqueue is running in your system because sem_open() will fail and subsequent sem_*() calls on such semaphore structure will fail if it’s not running…)
bottom line: the “sem 5689cc0” state of both processes would suggest inproper usage of the sem_*() functions