1

My command fails with what I think is a thread dump or something. Since I want to inspect, I would like to redirect the output to a file or less. However the output doesn't seem to be on stderr or stdout?! How can I capture this output?

7f47efcda000-7f47efcdb000 r--p 00000000 fc:00 174138                     /usr/lib/libgtest_main.so.0.0.0
7f47efcdb000-7f47efcdc000 rw-p 00001000 fc:00 174138                     /usr/lib/libgtest_main.so.0.0.0
7f47efcdc000-7f47efd25000 r-xp 00000000 fc:00 174141                     /usr/lib/libgtest.so.0.0.0
7f47efd25000-7f47eff25000 ---p 00049000 fc:00 174141                     /usr/lib/libgtest.so.0.0.0
7f47eff25000-7f47eff26000 r--p 00049000 fc:00 174141                     /usr/lib/libgtest.so.0.0.0
7f47eff26000-7f47eff27000 rw-p 0004a000 fc:00 174141                     /usr/lib/libgtest.so.0.0.0
7f47eff27000-7f47eff28000 rw-p 00000000 00:00 0
7f47eff28000-7f47eff4e000 r-xp 00000000 fc:00 899                        /lib/x86_64-linux-gnu/ld-2.23.so
7f47f00c6000-7f47f00e2000 rw-p 00000000 00:00 0
7f47f00e2000-7f47f0100000 r-xp 00000000 fc:00 422                        /lib/x86_64-linux-gnu/libudev.so.1.6.4
7f47f0100000-7f47f0101000 r--p 0001d000 fc:00 422                        /lib/x86_64-linux-gnu/libudev.so.1.6.4
7f47f0101000-7f47f0102000 rw-p 0001e000 fc:00 422                        /lib/x86_64-linux-gnu/libudev.so.1.6.4
7f47f0102000-7f47f0132000 rw-p 00000000 00:00 0
7f47f014c000-7f47f014d000 rw-p 00000000 00:00 0
7f47f014d000-7f47f014e000 r--p 00025000 fc:00 899                        /lib/x86_64-linux-gnu/ld-2.23.so
7f47f014e000-7f47f014f000 rw-p 00026000 fc:00 899                        /lib/x86_64-linux-gnu/ld-2.23.so
7f47f014f000-7f47f0150000 rw-p 00000000 00:00 0
7ffca7f25000-7ffca7f46000 rw-p 00000000 00:00 0                          [stack]
7ffca7f84000-7ffca7f86000 r--p 00000000 00:00 0                          [vvar]
7ffca7f86000-7ffca7f88000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
2/2 Test #2: subscriberSkeleton_gtest .........***Exception: Other  0.03 sec

0% tests passed, 2 tests failed out of 2

Total Test time (real) =   0.07 sec

I tried variations of make test 2> file, make test 2>&1 | less, these only output the last lines, not the dump.

The code in question is just this:

#include <gtest/gtest.h>

int main(int argc, char **argv) {
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

The issue that makes this program fail is that it is linked together with OpenCV, which contains a testing component opencv_ts that conflicts with GTest. Blog post of someone with the same problem. I know how to solve this, but am stumped as to why I can't capture the output that is produced by the error.

kenorb
  • 155,785
  • 88
  • 678
  • 743
kutschkem
  • 7,826
  • 3
  • 21
  • 56
  • What output is this from? and how did you attempt to capture this? – Inian Mar 16 '18 at 10:56
  • You are probably looking for redirection (i.e. "2> logfile"), for example: `command 2> error.log`. – Micha Wiedenmann Mar 16 '18 at 11:02
  • @MichaWiedenmann I tried this but for some reason this does not capture the big block of the dump, just the "normal" output of the CTest program. – kutschkem Mar 16 '18 at 11:09
  • @Inian This output is coming from a segfault, the same problem as this guy: https://schneide.wordpress.com/2014/02/03/testing-c-code-with-opencv-dependencies/ – kutschkem Mar 16 '18 at 11:10

1 Answers1

2

this is probably glibc producing output, for example when you have double-free()s. Setting the following environment variable may help: LIBC_FATAL_STDERR_=1 (The output will then be in STDERR.)

However, with the output you pasted this could also be kernel output, which happens independently from your program.

sneep
  • 1,828
  • 14
  • 19
  • Yes, this is indeed a double free problem. – kutschkem Mar 16 '18 at 11:23
  • Sorry, it's `LIBC_FATAL_STDERR_=1`, with a trailing underscore. – sneep Mar 16 '18 at 11:27
  • Ah yes, that does something. Now I don't see the output at all, but that might just be a mistake on my side. – kutschkem Mar 16 '18 at 11:29
  • `LIBC_FATAL_STDERR_=1 ./double_free 2>&1 | less` seems to work for me (where double_free is a program that does a double-free()) – sneep Mar 16 '18 at 11:31
  • Veeeery odd but if `LIBC_FATAL_STDERR_` is undefined the output shows but can't be captured, when it is defined the output does not show at all (but the program is still broken). – kutschkem Mar 16 '18 at 11:51
  • Does it work with a smaller test case? double_free.c #include int main() { char *foo = malloc(10); free(foo); free(foo); } – sneep Mar 16 '18 at 11:53
  • Hmm... Maybe you could share some of the surrounding bash code or try planting in the double_free program instead. – sneep Mar 16 '18 at 12:28
  • I don't know, maybe this isn't double-free after all. The problem is described here: https://schneide.wordpress.com/2014/02/03/testing-c-code-with-opencv-dependencies/ Would a segfault produce output like I showed? – kutschkem Mar 16 '18 at 12:58
  • Okay, looks like it's something to do with gtest. I googled for 'gtest capture stdout' and hit on e.g.: https://stackoverflow.com/questions/3803465/how-to-capture-stdout-stderr-with-googletest I don't know how gtest works, but setting LIBC_FATAL_STDERR_=1 possibly prevents gtest from getting the glibc output. (There are other ways to get at this output) – sneep Mar 16 '18 at 14:08