perror() 给出段。过错答案

【问题标题】：perror() give seg. faultperror() 给出段。过错
【发布时间】：2012-09-24 21:35:36
【问题描述】：

发生错误后，我自然会调用perror()。但是当我这样做时遇到了分段错误，或者printf("error: %s\n", strerror(errno)); 我不知道发生了什么。

  int fd;
  if((fd = open(FILENAME, O_RDONLY)) == -1) {
    perror("fbi");
    exit(1);
  }

  for(;;) {

    readed = read(fd, buffer, BUFSIZE);

    if(readed == 0)
      break;

    if(readed == -1) {
      perror("fbi"); // <- here's the error
      exit(1);
    }

如何解决这个问题？

更新：

printf("%d\n", errno); // given 9

更新 2：

看起来与recv() 函数中传递的缓冲区大小有关。如果BUFSIZE 是1，则给出上述错误。但是如果BUFSIZE 是例如128 没有错误。有人可以解释这种行为吗？

【问题讨论】：

您是否尝试过使用 gdb 之类的调试器？调用堆栈是什么？
听起来可能是（1）您的堆栈空间不足或（2）您超出了堆栈上的缓冲区并写入了返回地址（尽管这第二个可能需要一些时髦的其他线程之类的东西）
@AdamRosenfield：通过使用gdb我发现错误来自getenv()函数：0xb7e84011 in getenv () from /lib/libc.so.6
确保将有效的 C 字符串传递给 getenv()。
我没有调用 getenv()。 perror() 调用它

标签： c linux gcc posix errno

【解决方案1】：

不可能从这个 sn-p 中确切知道哪里出了问题。但总的来说，“为什么我在调用 [rock solid c library func here] 时会出现段错误”这个问题的答案？通常是：你的堆栈是油炸的。阅读，当然是一个主要的嫌疑人。

【讨论】：

【解决方案2】：

一定要#include <string.h>等。

我在宏中使用#include <errno.h>[...]printf("%s\n",strerror(errno));[...] 几天都没有问题。然后有一天我向strerror(errno) 添加了另一个调用，结果包括奇怪的行为、分段错误、不正确的返回类型、意外的程序终止（退出状态为0），这一切都取决于我如何调用第二个strerror。

像strerror(errno)==NULL 这样简单的东西会导致warning: comparison between pointer and integer。

原来是因为我使用了strerror 而没有#include <string.h>。由于函数被正确链接为标准 c 库的一部分，因此编译器会创建一个（标准强制）该函数的“隐式声明”，该函数假定定义为 int strerror(int)。不兼容的返回类型会导致问题，因为在我的系统上 char* 是 64 位，但 int 是 32 位。因此，取决于编译器如何安排内存空间，有时指针将适合 32 位，有时它们不会，有时不正确的地址恰好匹配其他分配的内存页面（未定义/空白输出），有时它们不匹配（分段过错）。我碰巧遇到了不适合 32 位的情况，编译器将返回值“转换”为 32 位 int，然后将其转换回（对于 printf）为 64 位 char* （没有丢失的 64 位的上半部分，现在为零），当处理器尝试从未分配的内存页面读取时，会出现未定义的行为。

诊断您的特殊情况需要short, self contained, compilable, example (SSCCE)，例如您引用recv 函数调用（我假设您的意思是阅读？）。

您还需要包含用于编译代码的命令，例如，链接命令的顺序可能会显着改变生成代码的行为。

【讨论】：