With pdns-2.9.22-3.el5, sending SIGSTOP and SIGCONT to a running pdns_server (for example, by launching it from the shell, pressing Control-Z, and typing fg) reliably causes it to immediately segfault: # yum -y install pdns # echo 'launch=bind' >> /etc/pdns/pdns.conf # pdns_server Nov 12 22:23:12 Reading random entropy from '/dev/urandom' Nov 12 22:23:12 This is a standalone pdns Nov 12 22:23:12 Listening on controlsocket in '/var/run/pdns.controlsocket' Nov 12 22:23:12 It is advised to bind to explicit addresses with the --local-address option Nov 12 22:23:12 UDP server bound to 0.0.0.0:53 Nov 12 22:23:12 TCP server bound to 0.0.0.0:53 Nov 12 22:23:12 PowerDNS 2.9.22 (C) 2001-2009 PowerDNS.COM BV (Jan 26 2009, 12:01:27, gcc 4.1.2 20080704 (Red Hat 4.1.2-44)) starting up Nov 12 22:23:12 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. Nov 12 22:23:12 Creating backend connection for TCP Nov 12 22:23:12 About to create 3 backend threads for UDP Nov 12 22:23:12 Done launching threads, ready to distribute questions ^Z [1]+ Stopped pdns_server # fg pdns_server Nov 12 22:23:13 Got a signal 11, attempting to print trace: Nov 12 22:23:13 pdns_server [0x485ce6] Nov 12 22:23:13 /lib64/libc.so.6 [0x2b0ec242e2d0] Nov 12 22:23:13 pdns_server(_ZN11DistributorI9DNSPacketS0_13PacketHandlerE10makeThreadEPv+0x12c) [0x4c788c] Nov 12 22:23:13 /lib64/libpthread.so.0 [0x2b0ec21e873d] Nov 12 22:23:13 /lib64/libc.so.6(clone+0x6d) [0x2b0ec24d1f6d] Aborted Attempting to run pdns_server under gdb also causes it to immediately segfault (probably because SIGSTOP is involved in the implementation of ptrace): (gdb) run Starting program: /usr/sbin/pdns_server [Thread debugging using libthread_db enabled] Nov 12 22:43:14 Reading random entropy from '/dev/urandom' Nov 12 22:43:14 This is a standalone pdns Nov 12 22:43:14 Listening on controlsocket in '/var/run/pdns.controlsocket' Nov 12 22:43:14 It is advised to bind to explicit addresses with the --local-address option Nov 12 22:43:14 UDP server bound to 0.0.0.0:53 Nov 12 22:43:14 TCP server bound to 0.0.0.0:53 Nov 12 22:43:14 PowerDNS 2.9.22 (C) 2001-2009 PowerDNS.COM BV (Jan 26 2009, 12:01:27, gcc 4.1.2 20080704 (Red Hat 4.1.2-44)) starting up Nov 12 22:43:14 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. [New Thread 0x40a00940 (LWP 2335)] Nov 12 22:43:14 Creating backend connection for TCP [New Thread 0x41401940 (LWP 2336)] Nov 12 22:43:14 About to create 3 backend threads for UDP [New Thread 0x41e02940 (LWP 2337)] [New Thread 0x42803940 (LWP 2338)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41e02940 (LWP 2337)] 0x00002aaaab197672 in __gnu_cxx::__exchange_and_add (__mem=0xfffffffffffffff8, __val=-1) at atomicity.cc:41 41 : "0" (__val), "m" (*__mem)); (gdb) bt full #0 0x00002aaaab197672 in __gnu_cxx::__exchange_and_add ( __mem=0xfffffffffffffff8, __val=-1) at atomicity.cc:41 __result = -1 #1 0x00000000004c7c1e in Distributor<DNSPacket, DNSPacket, PacketHandler>::makeThread (p=0x791830) at /usr/include/c++/4.1.2/bits/basic_string.h:232 b = 0x792150 qcount = 0 queuetimeout = 1500 #2 0x00002aaaab87873d in start_thread (arg=<value optimized out>) at pthread_create.c:301 __res = <value optimized out> pd = 0x41e02940 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1105209664, 197107770085693007, 10485760, 3, 1105211392, 4096, 197107769030834047, 197154333293990220}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 robust = <value optimized out> #3 0x00002aaaabb61f6d in clone () from /lib64/libc.so.6 No symbol table info available.
Also reported upstream: http://wiki.powerdns.com/trac/ticket/326
Created attachment 460173 [details] Handle EINTR from sem_wait() The problem seems to be that Semaphore::wait() does not handle the case of sem_wait() returning EINTR. I’ve attached a patch to fix this, and also sent it upstream.
Thanks for the report. My first gut instinct is "don't do that then", but I'm sure you have a specific use-case in mind. I'm a bit hesitant to push a new version to EPEL without upstream having at least looked at the patch.
Upstream has applied this in r1747. svn {log|diff} svn://svn.powerdns.com/pdns/trunk/pdns -c1747
pdns-2.9.22-10.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pdns-2.9.22-10.fc14
pdns-2.9.22-10.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/pdns-2.9.22-10.fc13
pdns-2.9.22-10.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pdns'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/pdns-2.9.22-10.fc14
pdns-2.9.22-10.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
pdns-2.9.22-10.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.