Hi,

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.


Strangely, gdb also crashes:
$ gdb x86_64-redhat-linux-gnu/test-terminal-util
GNU gdb (GDB) Fedora 8.3.50.20190321-3.fc31
...
Reading symbols from x86_64-redhat-linux-gnu/test-terminal-util...
(gdb) r
Starting program: 
/builddir/build/BUILD/systemd-49bd196d693efe0acfc8d56c4e3d8f7ba9f91b5d/x86_64-redhat-linux-gnu/test-terminal-util
 
Missing separate debuginfos, use: dnf debuginfo-install 
glibc-2.29.9000-8.fc31.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
/* test_default_term_for_tty */
...
/* test_read_one_char */

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e759ec in fputs () from /lib64/libc.so.6
Segmentation fault (core dumped)


There also are compilation failures related to inlining, when I disable LTO:

In file included from ../src/basic/macro.h:549,
                 from ../src/basic/alloc-util.h:9,
                 from ../src/network/networkd-link.c:9:
In function ‘link_enable_ipv6’,
    inlined from ‘link_set_mtu’ at ../src/network/networkd-link.c:1483:16:
../src/basic/log.h:104:9: error: ‘%s’ directive argument is null 
[-Werror=format-overflow=]
  104 |         log_internal_realm(LOG_REALM_PLUS_LEVEL(LOG_REALM, (level)), 
__VA_ARGS__)
      |         
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/log-link.h:21:25: note: in expansion of macro ‘log_internal’
   21 |                         log_internal(level, error, __FILE__, __LINE__, 
__func__, ##__VA_ARGS__); \
      |                         ^~~~~~~~~~~~
../src/shared/log-link.h:33:50: note: in expansion of macro ‘log_link_full’
   33 | #define log_link_warning_errno(link, error, ...) log_link_full(link, 
LOG_WARNING, error, ##__VA_ARGS__)
      |                                                  ^~~~~~~~~~~~~
../src/network/networkd-link.c:324:17: note: in expansion of macro 
‘log_link_warning_errno’
  324 |                 log_link_warning_errno(link, r, "Cannot %s IPv6 for 
interface %s: %m",
      |                 ^~~~~~~~~~~~~~~~~~~~~~
../src/network/networkd-link.c: In function ‘link_set_mtu’:
../src/network/networkd-link.c:324:79: note: format string is defined here
  324 |                 log_link_warning_errno(link, r, "Cannot %s IPv6 for 
interface %s: %m",
      |                                                                         
      ^~

The argument is field in a structure, and when the structure is
created, it is always set. It's hard to say for sure that it's never
null, but I think gcc must be confused when it says it's *always* null.

The same rpm compiles fine with gcc-9.0.1-0.8.fc30, gcc-9.0.1-0.8.fc31.
I'm writing to the mailing list instead of opening a bug because I'm not
really sure if gcc is at fault, or if systemd code is somehow buggy in
a non-obvious way... Has anyone else seen similar failures with the
latest gcc build?

Zbyszek

example failed koji scratch build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=33792874
_______________________________________________
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

Reply via email to