2013-12-10 19 views
0

我在这里有一个相当奇怪的问题,或者我不知道它的工作方式,但任何方式我有下面的程序正确创建信号量并运行到第一次结束。但是,如果信号量已经存在,则在sem_wait处发生SEGFault。 我正在64位Fedora 17上运行此操作。是否必须对错误执行任何操作?在sem_wait Coredump

#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; 
} 

的/ 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 

奇怪的问题的内容是,当我删除的/ dev/shm的或取消注释sem_unlink旗语它屡试不爽。我在这里做错了什么或者是否需要在某处运行sem_post?

谢谢。

回答

4

如果sem_open失败,则返回SEM_FAILED,它在我的系统(可能是其他人)上相当于NULL。检查而不是-1

此外,如果失败,则会打印实际错误(例如,使用perror()strerror())。

1

当试图对CPU无法物理寻址的特定内存时,通常会发生分段错误。硬件通知操作系统内存违规,作为响应的内核(OS)发送纠正措施,通常终止它或导致转储核心。分割最常见的原因是取消引用NULL指针。尝试一下可能会有所帮助。

+0

在我的情况下,有一件事我可能会误解。这些64位指针值是否相同? 0x7f0d0b8c0000和0xb8c1000。我在这里遇到了一个核心转储 – user1663533

+0

我认为代码与32位或64位指针值一样可以编写,编译和执行。大多数问题出现在/如果你做某些事情时,例如假设操作系统类型相似(例如,DWORD将保存一个指针 - 在32位代码中为true,而在64位代码中为true)。 – user3007735