Summary: | [-fstack-check] net-misc/ntp-4.2.8_p10-r1 segfaults when >=sys-libs/glibc-2.25-r8 is built with -fstack-check | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ortwin Glueck <odi> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alexander, herrtimson, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 637152 |
Description
Ortwin Glueck
2017-10-31 11:40:01 UTC
1) could you please try to get a backtrace? Easiest way would be to start it from gdb (if you havent done that anyway you may have to rebuild ntp with debug information). https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces 2) does the problem go away after rebuilding ntp? (I realize that this would make further debugging hard...) 3) if ntp still segfaults, what happens if oyu remove -fstack-check from your CFLAGS? Rebuilding of ntp did not help (I had tried that first of course). No backtrace unfortunately. It seems to crash during loading within ld. So it might not even be a problem of ntp itself, but entirely within glibc. I was unable to create debug symbols with: FEATURES="nostrip" CFLAGS="-ggdb" emerge -1 ntp That also got rid of -fstack-check by the way. (gdb) run -p /var/run/ntpd.pid -g Starting program: /usr/sbin/ntpd -p /var/run/ntpd.pid -g [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff7ff4700 (LWP 5202)] Thread 2 "ntpd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7ff4700 (LWP 5202)] 0x00007ffff7de1661 in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) bt #0 0x00007ffff7de1661 in ?? () from /lib64/ld-linux-x86-64.so.2 #1 0x0000000000000000 in ?? () strace ends with: [pid 5209] open("/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 [pid 5209] read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000*\0\0\0\0\0\0"..., 832) = 832 [pid 5209] fstat(3, {st_mode=S_IFREG|0644, st_size=92376, ...}) = 0 [pid 5209] mmap(NULL, 2188320, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f80ab8db000 [pid 5209] mprotect(0x7f80ab8f0000, 2097152, PROT_NONE) = 0 [pid 5209] mmap(0x7f80abaf0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f80abaf0000 [pid 5209] close(3) = 0 [pid 5209] mprotect(0x7f80abaf0000, 4096, PROT_READ) = 0 [pid 5209] munmap(0x7f80ad649000, 259532) = 0 [pid 5209] getpid() = 5209 [pid 5209] tgkill(5209, 5210, SIGRTMIN) = 0 [pid 5210] <... nanosleep resumed> {tv_sec=9, tv_nsec=999513235}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) [pid 5209] futex(0x7f80ad6ce9d0, FUTEX_WAIT, 5210, NULL <unfinished ...> [pid 5210] --- SIGRTMIN {si_signo=SIGRTMIN, si_code=SI_TKILL, si_pid=5209, si_uid=0} --- [pid 5210] getpid() = 5209 [pid 5210] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f80ad6cbf50} --- [pid 5209] <... futex resumed>) = ? [pid 5210] +++ killed by SIGSEGV +++ Trying with glibc built without -fstack-check. Woah! Dropping -fstack-check when building glibc-2.25 fixes the problem. I guess that flag better be filtered by the glibc ebuild then. Did you add -fstack-check on your own, or is this behavior the general case? (to disable for testing you'd choose to set -fno-fstack-check, right?) I have -fstack-check in make.conf (you guess why): CFLAGS="-march=native -O2 -pipe -fstack-check" To disable I have defined separate CFLAGS for glibc via package.env: https://wiki.gentoo.org/wiki//etc/portage/package.env same behaviour when glibc is compiled with gcc-6.4.0 (gdb) r Starting program: /usr/sbin/ntpd warning: File "/lib64/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /lib64/libthread_db-1.0.so line to your configuration file "/root/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. [New LWP 7012] Thread 2 "ntpd" received signal SIG32, Real-time event 32. [Switching to LWP 7012] 0x00007ffff72478e8 in nanosleep () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff72478e8 in nanosleep () from /lib64/libc.so.6 #1 0x00007ffff7247789 in sleep () from /lib64/libc.so.6 #2 0x0000555555572f12 in ?? () #3 0x00007ffff754ba76 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff727f05f in clone () from /lib64/libc.so.6 (gdb) (gdb) c Continuing. Thread 2 "ntpd" received signal SIGSEGV, Segmentation fault. 0x00007ffff7de14e4 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 (gdb) bt #0 0x00007ffff7de14e4 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 #1 0x00007ffff7de6893 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #2 0x00007ffff7dee07a in _dl_runtime_resolve_xsave () from /lib64/ld-linux-x86-64.so.2 #3 0x00007ffff6d69873 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 #4 0x00007ffff6d6aaa0 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 #5 0x00007ffff6d6b0ad in _Unwind_ForcedUnwind () from /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 #6 0x00007ffff75572ef in __pthread_unwind () from /lib64/libpthread.so.0 #7 0x00007ffff7549d3a in sigcancel_handler () from /lib64/libpthread.so.0 #8 <signal handler called> #9 0x00007ffff72478e8 in nanosleep () from /lib64/libc.so.6 #10 0x00007ffff7247789 in sleep () from /lib64/libc.so.6 #11 0x0000555555572f12 in ?? () #12 0x00007ffff754ba76 in start_thread () from /lib64/libpthread.so.0 #13 0x00007ffff727f05f in clone () from /lib64/libc.so.6 (gdb) OK we need to figure out if/how we want to handle this on the glibc side. -fstack-check was whitelisted in #607710. The backtrace looks like a bug in pthread_cancel(). Does it still happen on current stable glibc? Can you post your ntpd config and the exact command to run so I could reproduce it locally? |