Hello, I've a very strange symbol renaming issue on NetBSD 8.0/amd64: syslog-ng dies with a bad syscall signal, ktrace reveals that it called compat_13_sigaction13, just after properly calling __sigprocmask14. gdb on the core dump shows: Core was generated by `syslog-ng'. Program terminated with signal SIGSYS, Bad system call. #0 0x00007747ad46e74a in sigaction () from /usr/lib/libc.so.12 (gdb) up #1 0x00007747b0e38f38 in g_process_perform_supervise () at lib/gprocess.c:1087 1087 sigaction(SIGHUP, &sa, NULL); (gdb)
but gprocess.c properly includes signal.h, there was no warning at link time, and disasembling the function confirms it: 0x00007747b0e38f08 <+143>: movq $0x0,0x58(%rsp) 0x00007747b0e38f11 <+152>: movq $0x0,0x60(%rsp) 0x00007747b0e38f1a <+161>: movq $0x0,0x68(%rsp) 0x00007747b0e38f23 <+170>: movq $0x1,0x50(%rsp) 0x00007747b0e38f2c <+179>: xor %edx,%edx 0x00007747b0e38f2e <+181>: mov $0x1,%edi 0x00007747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt> => 0x00007747b0e38f38 <+191>: mov $0x1,%ebp 0x00007747b0e38f3d <+196>: lea 0x4c(%rsp),%r15 0x00007747b0e38f42 <+201>: lea 0x41378(%rip),%r14 # 0x7747b0e7a2c1 >From here gdb seems lost; I'm working on a core dump as this all happens after a fork so I can't work on it live: (gdb) disas 0x7747b0e2f700 Dump of assembler code for function __sigaction14@plt: 0x00007747b0e2f700 <+0>: jmpq *0x2834a2(%rip) # 0x7747b10b2ba8 0x00007747b0e2f706 <+6>: pushq $0x4e5 0x00007747b0e2f70b <+11>: jmpq 0x7747b0e2a8a0 0x7747b10b2ba8 is in _GLOBAL_OFFSET_TABLE_ (gdb) x/lx 0x7747b10b2ba8 0x7747b10b2ba8: 0xb0e46527 (gdb) disas 0xb0e46527 No function contains specified address. (gdb) x/i 0xb0e46527 0xb0e46527: Cannot access memory at address 0xb0e46527 Any idea what could cause a program actually calling explicitely __sigaction14 to end up in the compat sigaction ? -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --