ntpd hangs under FBSD 8

[Peter Steele]

>You're going to need a debug version of libc, too.  gdb won't be able to find a backtrace out of a libc function without it.

What's the proper way to build a debug version of libc and the other libraries? I tried this:

export CFLAGS="-O0"
make buildworld
make installworld DESTDIR=/mydir

and then copied libc.so.7 from /mydir/lib to the /lib dir on my target system. I also replaced the ntpd binary with the debug version. I can see that -O0 is being used in the various "cc" commands that are generated, but libc still doesn't seem to be built properly. When I attach to a hung ntpd process, I get this:

# gdb /usr/sbin/ntpd -p 2113
GNU gdb 6.1.1 [FreeBSD]
...
Attaching to program: /usr/sbin/ntpd, process 2113
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
...
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
...
[Switching to Thread 8012041c0 (LWP 100283)]
0x0000000800dbeddc in select () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800dbeddc in select () from /lib/libc.so.7
#1  0x00000000004335de in ntpdmain ()
#2  0x000000000043310b in main ()

So I'm getting some symbols from ntpd but I still can't see into select(). It hangs in there forever so that's where I need to drill down further. How do I get libc built with full debug symbols?

In other testing I've narrowed the problem down to some kind of Python issue. If I run the Python code at the end of this email where "ntpd -g -q" is launched as part of a Python thread class, the command hangs (the code assumes that ntpd is not already running). If I run the same ntpd command in a normal function (e.g. main) no hang occurs. I've tried subcommand.Popen and os.spawnv to run ntpd and these calls behave exactly the same way--when called from a thread the ntpd process hangs but it works fine when called from outside of a thread. This is a breakdown of course of our larger project into a simple test app. In our real code we cannot so easily eliminate this thread wrapper.

The same code BTW works fine on our FreeBSD 7 boxes, the main difference being we are running an older version of Python on those boxes (2.5.1 instead of 2.6.2). I tried installing the same 2.5.1 package on a FBSD 8 box and that solved the problem. Curiously a slightly newer FBSD 7 version of Python, 2.5.5, causes the same hang to occur. So only Python 2.5.1 built under FreeBSD 7 works to get around this issue with ntpd on FreeBSD 8. That means one potential solution is to downgrade to this 2.5.1, but we have other libraries targeted to work with Python 2.6 and we don't really want to downgrade all these associated libraries.

If anyone has any clues at all as to what is causing this issue, I'd appreciate the feedback. Here's the code that reproduces this behavior.

#! /usr/bin/env python
import os
import threading

class RunProc(threading.Thread):
    def __init__(self, cmd):
        threading.Thread.__init__(self)
        self.cmd = cmd

    def run(self):
        os.system(self.cmd)

def main():
    RunProc("/usr/sbin/ntpd -g -q").start()

if __name__ == "__main__":
    main()