系统调用-open函数的oflags参数引起的调试经历

         原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://blog.csdn.net/tobyaries/article/details/8280088

 

        这篇博文可能放在这个类别也许并不合适，放在这里完全是因为是我在实验《Beginning Linux Programming》（Linux程序设计）一书中的一个进程通信例子的调试经历。这个例子是Page.449 （陈建 宋健建 译本）的实验："打开FIFO文件"。

        完成输入、编译、运行 ./fifo2 O_RDONLY 得到的是 process XXX  result -1。根据代码可以判断，显然这句出错时因为代码

        res = open(FIFO_NAME, open_mode);

        为什么返回值是-1呢？在书中Page.83 中给了些线索： “open调用在成功时返回一个新的文件描述符（他总是一个非负整数），失败时返回-1，并设置全局变量errno以指明失败的原因。”  

        也就是说我需要打印errno来看是什么问题导致返回-1。在平时调试工作中，这种加打印的办法很常见。说点题外话，上次电面一家知名的外企通信公司，有个问题就是平时工作中的调试手段，比如如何判断出系统发生了死锁。常见的调试法就是：1）通过调试工具，如gdb看函数调用栈；2）加打印；3）看门狗，一旦失活就说明有问题、

        在fifo2.c中，我打印了errno的值，为17 。接下来就需要找到系统中的errno了。那么如何找到自己系统中的errno呢？我用的方法是直接find / -name errno.h 而且一般都会放在标准路径下，如 /usr/include/.. 我的是在 /usr/inlude/asm-generic  下面。可以找到17对应的异常为EEXITS。

        我很纳闷为什么会返回文件存在的出错？fifo_name虽然有了，打开不就行了没，也没必要返回出错吧。。。后来突然想到 open_mode这个标志位。如果open_mode是O_CRATE,是不是新创建文件就无所谓，而如果是同时包含了O_EXCL标志位，就必须是新创建的文件。O_EXCL就是为了检测文件是否是新建的。因此肯定是open_mode出错了，顺藤摸瓜，发现open_mode没有初始化。。。原书无误，是我敲代码时候忘记了。open_mode初始化为0后就ok了。

       我认为如果没有初始化，open_mode会被随机赋值，最有可能赋值的就是 O_CRATE | O_EXCL

 

本文出自 “i小跟班” 博客，请务必保留此出处http://blog.csdn.net/tobyaries/article/details/8280088