1

当我的 C++ 程序尝试将一些 .png 图像写入目录时，会发生一些溢出运行时错误。

写入图像的目录作为命令行参数给出。该程序使用 gcc -ggdb3 -O3 编译。奇怪的是，如果我在重新运行时将目录更改为另一个目录，或者如果我在没有优化的情况下编译我的程序，错误就会消失。我很困惑。即使我可以获得由非优化可执行文件或其他目录生成的图像，我怀疑结果是否可靠，因为优化的可执行文件可能存在运行时错误？或者优化是否有可能产生容易出错的可执行文件？谁能解释一下？

我试图调试优化的可执行文件，因为它是用 gcc -ggdb3 -O3 编译的，但是它产生溢出错误的地方没有给出源代码，我无法从中获得一些线索：

(gdb) BT

#0 0x00007fbd29573fb5 in raise () from /lib/libc.so.6

#1 0x00007fbd29575bc3 in abort () from /lib/libc.so.6

#2 0x00007fbd295b3228 在?? () 来自 /lib/libc.so.6

#3 0x00007fbd296402c7 in __fortify_fail () from /lib/libc.so.6

#4 0x00007fbd2963e170 in __chk_fail () from /lib/libc.so.6

#5 0x00007fbd2963d519 在?? () 来自 /lib/libc.so.6

#6 0x00007fbd295b7426 in _IO_default_xsputn () from /lib/libc.so.6

#7 0x00007fbd29586fdb in vfprintf () from /lib/libc.so.6

#8 0x00007fbd2963d5b9 in __vsprintf_chk () from /lib/libc.so.6

#9 0x00007fbd2963d500 in __sprintf_chk () from /lib/libc.so.6

#10 0x0000000000408695 在 main ()

(gdb) f 10

#10 0x0000000000408695 在 main ()

当前语言：自动；目前asm

(gdb) 列表

1 /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S：没有这样的文件或目录。

在 /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S

(gdb)

我不确定运行时错误的输出是否有助于分析问题。如果可以的话，这是错误消息的样子，虽然有点长：

* 检测到缓冲区溢出 * : /cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity 终止

[新线程 0x7fbd2acd9740 (LWP 2347)]

======= 回溯：=========

/lib/libc.so.6(__fortify_fail+0x37)[0x7fbd296402c7]

/lib/libc.so.6[0x7fbd2963e170]

/lib/libc.so.6[0x7fbd2963d519]

/lib/libc.so.6(_IO_default_xsputn+0x96)[0x7fbd295b7426]

/lib/libc.so.6(_IO_vfprintf+0x63b)[0x7fbd29586fdb]

/lib/libc.so.6(__vsprintf_chk+0x99)[0x7fbd2963d5b9]

/lib/libc.so.6(__sprintf_chk+0x80)[0x7fbd2963d500]

/cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity[0x408695]

/lib/libc.so.6(__libc_start_main+0xe6)[0x7fbd2955f5a6]

/cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity[0x4045d9]

======= 内存映射：========

00400000-00471000 r-xp 00000000 00:39 52084894 /cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity

00671000-00672000 r--p 00071000 00:39 52084894 /cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity

00672000-00673000 rw-p 00072000 00:39 52084894 /cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity

00673000-00675000 rw-p 00673000 00:00 0

00943000-00964000 rw-p 00943000 00:00 0 [堆]

7fbd273f7000-7fbd29339000 rw-p 7fbd273f7000 00:00 0

7fbd29339000-7fbd29340000 r-xp 00000000 08:01 35791448 /lib/librt-2.9.so

7fbd29340000-7fbd2953f000 ---p 00007000 08:01 35791448 /lib/librt-2.9.so

7fbd2953f000-7fbd29540000 r--p 00006000 08:01 35791448 /lib/librt-2.9.so

7fbd29540000-7fbd29541000 rw-p 00007000 08:01 35791448 /lib/librt-2.9.so

7fbd29541000-7fbd296a9000 r-xp 00000000 08:01 35791428 /lib/libc-2.9.so

7fbd296a9000-7fbd298a9000 ---p 00168000 08:01 35791428 /lib/libc-2.9.so

7fbd298a9000-7fbd298ad000 r--p 00168000 08:01 35791428 /lib/libc-2.9.so

7fbd298ad000-7fbd298ae000 rw-p 0016c000 08:01 35791428 /lib/libc-2.9.so

7fbd298ae000-7fbd298b3000 rw-p 7fbd298ae000 00:00 0

7fbd298b3000-7fbd298c9000 r-xp 00000000 08:01 35790870 /lib/libgcc_s.so.1

7fbd298c9000-7fbd29ac9000 ---p 00016000 08:01 35790870 /lib/libgcc_s.so.1

7fbd29ac9000-7fbd29aca000 r--p 00016000 08:01 35790870 /lib/libgcc_s.so.1

7fbd29aca000-7fbd29acb000 rw-p 00017000 08:01 35790870 /lib/libgcc_s.so.1

7fbd29acb000-7fbd29ad3000 r-xp 00000000 08:01 71705955 /usr/lib/libgomp.so.1.0.0

7fbd29ad3000-7fbd29cd2000 ---p 00008000 08:01 71705955 /usr/lib/libgomp.so.1.0.0

7fbd29cd2000-7fbd29cd3000 r--p 00007000 08:01 71705955 /usr/lib/libgomp.so.1.0.0

7fbd29cd3000-7fbd29cd4000 rw-p 00008000 08:01 71705955 /usr/lib/libgomp.so.1.0.0

7fbd29cd4000-7fbd29d58000 r-xp 00000000 08:01 35791436 /lib/libm-2.9.so

7fbd29d58000-7fbd29f57000 ---p 00084000 08:01 35791436 /lib/libm-2.9.so

7fbd29f57000-7fbd29f58000 r--p 00083000 08:01 35791436 /lib/libm-2.9.so

7fbd29f58000-7fbd29f59000 rw-p 00084000 08:01 35791436 /lib/libm-2.9.so

7fbd29f59000-7fbd2a04a000 r-xp 00000000 08:01 71704918 /usr/lib/libstdc++.so.6.0.10

7fbd2a04a000-7fbd2a24a000 ---p 000f1000 08:01 71704918 /usr/lib/libstdc++.so.6.0.10

7fbd2a24a000-7fbd2a251000 r--p 000f1000 08:01 71704918 /usr/lib/libstdc++.so.6.0.10

7fbd2a251000-7fbd2a253000 rw-p 000f8000 08:01 71704918 /usr/lib/libstdc++.so.6.0.10

7fbd2a253000-7fbd2a266000 rw-p 7fbd2a253000 00:00 0

7fbd2a266000-7fbd2a27d000 r-xp 00000000 08:01 35791446 /lib/libpthread-2.9.so

7fbd2a27d000-7fbd2a47c000 ---p 00017000 08:01 35791446 /lib/libpthread-2.9.so

7fbd2a47c000-7fbd2a47d000 r--p 00016000 08:01 35791446 /lib/libpthread-2.9.so

7fbd2a47d000-7fbd2a47e000 rw-p 00017000 08:01 35791446 /lib/libpthread-2.9.so

7fbd2a47e000-7fbd2a482000 rw-p 7fbd2a47e000 00:00 0

7f

程序收到信号 SIGABRT，已中止。

[切换到线程 0x7fbd2acd9740 (LWP 2347)]

0x00007fbd29573fb5 in raise () from /lib/libc.so.6

非常感谢您的帮助！

谢谢并恭祝安康！

@@UPDATE@@：你们是对的！我为长文件名增加了 char 数组的大小，现在可以了！

可执行文件是 /cis/home/tim/research/absurdity/absurditylinux/binio21/release/absurdity。不起作用的目录被指定为命令行参数--result-path=../results1/FrancContinuity1/noise0/train-imgs，它存储在下面的global.result_path中。

你们能告诉我你如何怀疑这是你提到的问题吗？__sprintf_chk () 和 __vsprintf_chk () 是否总是被 sprintf() 调用？

这是代码。

第1部分：

      char filename[50];
      sprintf(filename, "%s/%d_%d.png", global.result_path, train_samples[n].label, train_samples[n].label==1 ? ++nb_pos : ++nb_neg);
      train_samples[n].write_png(filename);

第2部分：

class Global { //parameters of program
public:
  int niceness; //The process scheduling priority
  int random_seed; //The seed for the random sequence used in the computation
  char result_path[1024]; //Where to store the generated results (images, logs, etc.)
...
}

Global global;
4

4 回答 4

3

目录名称有多长，您要存储它的缓冲区有多长？你没有给我们太多继续......展示一些代码怎么样？也许在 main() 的某个地方调用 sprintf，以及所涉及的任何变量的声明？

编辑：鉴于您的输入目录和附加到它的文件名，看起来文件名确实需要更大的数组！快速修复：尝试将其声明为 1500 个字符而不是 50 个字符。更好的解决方法：由于您使用的是 C++，请查看 std::string 和 ostringstream 类，它们将调整自身大小以防止缓冲区溢出。

要回答您的后续问题：

结果路径中的“../”不应扩展为绝对路径。

我对 sprintf() 的预感是一个幸运的猜测，基于“缓冲区溢出”消息和 gdb 回溯中的最后几行。我对 glibc 的内部结构不太熟悉，但也许是 sprintf()__sprintf_chk()的__vsprintf_chk() 缓冲区溢出检查变体？

于 2009-09-03T00:01:10.967 回答
2

我很久以前就养成了到处使用 snprintf 的习惯。学会爱它。它可能仍然无法写入正确的文件，但至少不会留下安全漏洞。

然后，在您开始想知道为什么您的程序要创建名为的文件之后，"this_is_a_long_file_na"您可以返回并修复它以使用缓冲区PATH_MAX或动态大小的 malloc 缓冲区。如果缓冲区需要更大，snprintf 将帮助您找到正确的大小。

或者您可以切换到 C++ 并使用 std::string。

于 2009-09-03T02:01:04.273 回答
1

好吧，您使用 sprintf 打印到长度为 50 的缓冲区“文件名 [50]”。现在您要打印的字符串是大小为 1024 的缓冲区，这让我觉得这是一个潜在的问题。当 global.result_path 长于 50 时会发生什么（实际上甚至更少，因为您也在打印整数），那么您就会溢出。

尝试使用 C++ std::string 和 std::stringstream，即：

//Part 1:

std::stringstream ss;
ss << global.result_path << /* other data */;
train_samples[n].write_png(ss.str().c_str());

//Part 2:

class Global
{
    std::string result_path;
    ...
}

使用上面的代码，您将永远不必担心字符缓冲区溢出或任何其他丑陋的东西。

于 2009-09-03T00:49:04.793 回答
1

result_path 太小。

只需将 result_path 更改为 1024。某些系统定义了宏 MAX_PATH。我还将 sprintf 更改为 snprintf，其大小为 sizeof(result_path)。

snprintf() 函数就像 sprintf() 一样，只是给出了缓冲区的长度。这可以防止缓冲区溢出。

返回值是写入的字符数。如果输出由于 buff_size 限制而被截断，则返回值是在有足够空间可用的情况下将写入最终字符串的字符数（不包括尾随的 '\0'）。

我怎么知道你有 sprintf 的问题是回溯。

IE

(gdb) bt

#0 0x00007fbd29573fb5 in raise () from /lib/libc.so.6

#1 0x00007fbd29575bc3 in abort () from /lib/libc.so.6

#2 0x00007fbd295b3228 in ?? () from /lib/libc.so.6

#3 0x00007fbd296402c7 in __fortify_fail () from /lib/libc.so.6

#4 0x00007fbd2963e170 in __chk_fail () from /lib/libc.so.6

#5 0x00007fbd2963d519 in ?? () from /lib/libc.so.6

#6 0x00007fbd295b7426 in _IO_default_xsputn () from /lib/libc.so.6

#7 0x00007fbd29586fdb in vfprintf () from /lib/libc.so.6

#8 0x00007fbd2963d5b9 in __vsprintf_chk () from /lib/libc.so.6

#9 0x00007fbd2963d500 in __sprintf_chk () from /lib/libc.so.6

#10 0x0000000000408695 in main ()

即你的代码中有一个函数 main 。并且 __sprintf_chk 是它失败的地方。你必须打电话给 sprintf。之后它就死了。所以我的猜测是你传递了不好的论点。sprintf 死得这么惨的唯一方法是缓冲区溢出。所以这是一个很好的假设，即您要打印的字符串太小。使用 snprintf 会更安全。然后您可以打印以调试结果。如果你这样做了，你会立即看到缓冲区太小，因为 result_path 会被截断为 50 个字符，并且程序不会崩溃（至少在那时:)。

于 2009-09-03T02:38:25.110 回答