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. > gdb crashes I'll defer to the gdb team. Is that with LTO only btw? No, LTO doesn't seem to be relevant, despite what I said earlier. With some programs (I tried a few, some crash, so don't, no idea what is the rule, but it seems that the very simple ones don't): In mock buildroot of systemd: $ ninja -C x86_64-redhat-linux-gnu systemd $ gdb x86_64-redhat-linux-gnu/systemd GNU gdb (GDB) Fedora 8.3.50.20190321-3.fc31 ... $ r ... Trying to run as user instance, but the system has not been booted with systemd. [Inferior 1 (process 2466) exited with code 01] Segmentation fault (core dumped) So the crash seems to be when returning to the gdb prompt, either because the debugee exited or crashed or hit a breakpoint (all three end the same). Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
