Hi,
On Thu, 2019-03-28 at 14:28 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Mar 28, 2019 at 02:14:31PM +0100, Jakub Jelinek wrote:
On Thu, Mar 28, 2019 at 08:52:18AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 27, 2019 at 01:55:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
I'm trying to compile systemd in koji and mock, and I'm getting suspicious crashes...
$ valgrind x86_64-redhat-linux-gnu/test-terminal-util /* test_default_term_for_tty */ ... /* test_read_one_char */ ==21== Invalid read of size 4 ==21== at 0x48C09EC: fputs (in /usr/lib64/libc-2.29.9000.so) ==21== by 0x109301: UnknownInlinedFun (test-terminal-util.c:43) ==21== by 0x109301: main (test-terminal-util.c:80) ==21== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==21== ==21== ==21== Process terminating with default action of signal 11 (SIGSEGV)
The problem is at this line, there is just a call to (a function which transitively calls) mkostemp(). It seems like the inlining is somehow going wrong.
It turns out that our test case was wrong. I was confused because the inlining causes the backtrace to report an unrelated spot.
So do you still need anything from me to debug?
Thanks. I need some advice mostly. There's still the question of bogus backtrace returned by valgrind. Is this a valgrind issue or the debug data produced by gdb or something else? If we cannot rely on backtraces with LTO, this would be a big drawback.
The above backtrace is produced by valgrind. The addresses should be correct, but as "UnknownInlinedFun" shows it has some trouble resolving the associated function/symbol names.
I don't know if LTO makes that valgrind bug worse.
If gdb works then you can also use gdb and valgrind together: https://tromey.com/blog/?p=731
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserv...
gdb probably can produce a better backtrace than valgrind.