我刚刚观察到二进制文件中出现极其罕见的停顿现象。
附加 gdb 并切换到相关线程会给出
(gdb) bt
#0 0x000000330a4db79d in write () from /lib64/libc.so.6
#1 0x000000330a471dd3 in _IO_new_file_write () from /lib64/libc.so.6
#2 0x000000330a473385 in _IO_new_do_write () from /lib64/libc.so.6
#3 0x000000330a4726df in _IO_new_file_overflow () from /lib64/libc.so.6
#4 0x000000330a46f437 in putc () from /lib64/libc.so.6
#5 0x00007f92d94864ea in sputc (__c=10 '\n', this=<optimized out>) at [..omitted..]/gcc-4.9.0-objdir/x86_64-linux-gnu/libstdc++-v3/include/streambuf:434
#6 std::ostream::put (this=0x3171f40 <std::cout>, __c=<optimized out>) at [..omitted..]/gcc-4.9.0-objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:163
strace 给出
Process 14702 attached - interrupt to quit
write(1, "[...some string...]", 31
它一直在那里,写入 std::cout。我还应该收集哪些其他信息?应该如何查明此事的真相?
编辑: 该二进制文件由 python 系统调用,在其内部非常深处,它正在执行
pipe = subprocess.Popen(
command,
shell=True,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT
)
output = pipe.stdout.read()
pipe.wait()
最佳答案
如果cout
被重定向到管道,那么如果管道另一端的进程读取速度不够快,输出将被阻塞。您需要决定是否应将 C++ 进程构造为即使写入 cout
block 也能继续前进,或者管道的另一端是否必须从管道读取。找出损坏的地方并修复它。
关于python - 调试停止从 libc.so.6 到 std::cout 的 write(),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27207928/