c++ - 将图像写入目录失败

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 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 ()

(gdb) f 10

#10 0x0000000000408695 in main ()

Current language: auto; currently asm

(gdb) list

1 /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S: No such file or directory.

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

(gdb)

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

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

[New Thread 0x7fbd2acd9740 (LWP 2347)]

======= Backtrace: =========

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

======= Memory map: ========

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 [heap]

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

Program received signal SIGABRT, Aborted.

[Switching to Thread 0x7fbd2acd9740 (LWP 2347)]

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

非常感谢您的帮助!

谢谢和问候!

---

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

可执行文件是/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() 的缓冲区溢出检查变体？