sem_wait的Coredump

Question

I have a rather strange issue here or I am be ignorant of the way it works, but any way I have the program below that creates the semaphore properly and runs to the end for the first time. But SEGFaults at sem_wait, if the semaphore already exists. I am running this on 64bit Fedora 17. Does this have to do anything with the error?

#include <stdio.h>          /* printf()                 */
#include <stdlib.h>         /* exit(), malloc(), free() */
#include <sys/types.h>      /* key_t, sem_t, pid_t      */
#include <sys/shm.h>        /* shmat(), IPC_RMID        */
#include <errno.h>          /* errno, ECHILD            */
#include <semaphore.h>      /* sem_open(), sem_destroy(), sem_wait().. */
#include <fcntl.h>          /* O_CREAT, O_EXEC          */

int
main() {


        sem_t *mysem;
        int oflag = O_CREAT | O_EXCL;
        mode_t mode = 0777;
        const char semname[] = "mysem";
        unsigned int value = 1;
        int sts;


        mysem = sem_open(semname, oflag, mode, value);
        //sem_unlink(semname);

        if(mysem == (void *)-1) {
                printf("sem_open() failed");
                exit(1);
        }

        printf("opened a semaphore successful\n");

        if(!sem_wait(mysem)) {
                /*locked */
                printf("worked\n");
        } else {
                printf("error\n");
        }
         return 0;
}

Contents of /dev/shm sem.mysem

Program received signal SIGSEGV, Segmentation fault.
0x000000332980d5f0 in sem_wait () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install glibc-2.15-58.fc17.x86_64
(gdb) where
#0  0x000000332980d5f0 in sem_wait () from /lib64/libpthread.so.0
#1  0x000000000040074a in main () at str2.c:31

Strange issue is that when I delete the semaphore in /dev/shm or uncomment sem_unlink it works every time. Am I doing something wrong here or do I need to run a sem_post somewhere?

thanks.

Answer 1

If sem_open fails it returns SEM_FAILED , which on my system (and probably everyone else) is the equivalent to NULL . Check against that instead of -1 .

Also, if it fails then print the actual error (use eg perror() or strerror() ).

Answer 2

Segmentation fault usually occurs when an attempt is made to a particular memory that CPU can not physically address. Hardware notifies OS about memory violation, the kernel (OS) in response sends a corrective action against it usually terminating it or causing a dump core. The most common cause of segmentation is dereferencing NULL pointers . Trying that out might help.

Answer 3

Check man open_sem:

"If both O_CREAT and O_EXCL are specified in oflag,then an error is returned if a semaphore with the given name already exists."

It looks like your semaphore already exists. That is why your code works again after removing from /dev/shm - so it can create it again w/o error.

I'm not sure why everyone is checking for -1 return value for error when man says SEM_FAILED. Probably used to behave like open. SEM_FAILED could be defined to be anything, you should not assume its value and use the MACRO.