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.gdbserver gdb probably can produce a better backtrace than valgrind. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
