Date: Wed, 24 Feb 2010 14:18:42 -0800 (PST) From: Nate Eldredge <nate@thatsmathematics.com> To: Peter Steele <psteele@maxiscale.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: RE: ntpd hangs under FBSD 8 Message-ID: <Pine.GSO.4.64.1002241415590.5432@zeno.ucsd.edu> In-Reply-To: <7B9397B189EB6E46A5EE7B4C8A4BB7CB385D60B7@MBX03.exg5.exghost.com> References: <7B9397B189EB6E46A5EE7B4C8A4BB7CB385D5C73@MBX03.exg5.exghost.com> <20100220113349.GA22800@kiwi.sharlinx.com> <7B9397B189EB6E46A5EE7B4C8A4BB7CB385D60B7@MBX03.exg5.exghost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Feb 2010, Peter Steele wrote: >> Just out of curiosity, can you attach to the process via gdb and get a >> backtrace? This smells like a locked pthread_join I hit in my own code >> a few weeks ago > > I'm not using the debug version of ntpd so the backtrace isn't too > useful, but here's what I get: > > (gdb) bt > #0 0x0000000800d52bfc in select () from /lib/libc.so.7 > #1 0x0000000000425273 in ?? () > #2 0x000000000040540e in ?? () > #3 0x0000000800580000 in ?? () > #4 0x0000000000000000 in ?? () I bet ntpd doesn't call select() in all that many places. Instead of going to all this trouble to build a debugging libc, you could just grep for select() and place breakpoints on all occurrences. (It might also be obvious from looking at them which one is the offender.) Also, since a system call is causing the trouble, you might learn something from truss or ktrace. -- Nate Eldredge nate@thatsmathematics.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1002241415590.5432>