>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()
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
