将图像写入目录失败

Question

当我的 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

来自 /lib/libc.so.6 的 __fortify_fail () 中的 #3 0x00007fbd296402c7

来自 /lib/libc.so.6 的 __chk_fail () 中的#4 0x00007fbd2963e170

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

来自 /lib/libc.so.6 的 _IO_default_xsputn () 中的 #6 0x00007fbd295b7426

来自 /lib/libc.so.6 的 vfprintf () 中的#7 0x00007fbd29586fdb

来自 /lib/libc.so.6 的 __vsprintf_chk () 中的#8 0x00007fbd2963d5b9

/lib/libc.so.6 中的 __sprintf_chk () 中的#9 0x00007fbd2963d500

main()中的#10 0x0000000000408695

（gdb）f 10

main()中的#10 0x0000000000408695

当前语言：自动；目前汇编

（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)]

来自/lib/libc.so.6的raise()中的0x00007fbd29573fb5

非常感谢您的帮助！

谢谢和问候！

---

@@更新@@： 你们是对的！我增加了长文件名的字符数组的大小，现在没问题了！

可执行文件是/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;

Answer 1

目录名称有多长，您尝试存储它的缓冲区有多长？您没有给我们太多的内容...展示一些代码怎么样？也许调用 sprintf
main() 中的某个位置以及所涉及的任何变量的声明？

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

回答您的后续问题：

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

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

Answer 2

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

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

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

Answer 3

好吧，您使用 sprintf 打印到缓冲区“filename[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;
    ...
}

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

Answer 4

result_path 太小。

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

snprintf() 函数与 sprintf() 类似，只是给出了缓冲区的长度。这可以防止缓冲区溢出。

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

我如何知道你的 sprintf 有问题是因为回溯。

即

(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 个字符，并且程序不会崩溃（至少在这一点上:)。