Date: Thu, 17 Dec 2009 10:52:35 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Steven Hartland <killing@multiplay.co.uk> Subject: Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug? Message-ID: <Pine.GSO.4.64.0912171051320.1844@sea.ntplx.net> In-Reply-To: <200912170908.49119.jhb@freebsd.org> References: <DD0B1DB4EEAE4FB49FFFE1FDF5E9D7E3@multiplay.co.uk> <200912170908.49119.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Dec 2009, John Baldwin wrote: > On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: >> We're having an issue with Passenger on FreeBSD where it will hang >> and stop processing any more requests the details are attach to >> the following bug report: >> http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 >> >> In addition the test suite crashes in what seems to be a very >> basic test, which I'm at a loss with. >> http://code.google.com/p/phusion-passenger/issues/detail?id=441 >> >> I'm thinking this may be a bugs in the FreeBSD either kernel or >> thread library as the crashes don't make any sense from the >> application side. >> >> Any advise on debugging or feedback on the stack traces would >> be much appreciated. > > For the hang it seems you have a thread waiting in a blocking read(), a thread > waiting in a blocking accept(), and lots of threads creating condition > variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) > doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to > me. However, that may be gdb getting confused. The pthread_cleanup_push() > frame may be cond_init(). However, it doesn't call umtx_op() (the > _thr_umutex_init() call it makes just initializes the structure, it doesn't > make a _umtx_op() system call). You might try posting on threads@ to try to > get more info on this, but your pthread_cond_init() stack traces don't really > make sense. Can you rebuild libc and libthr with debug symbols? Yes, good advice, I have noticed that you can't trust GDB stack traces unless libc and libthr have been built with debug (-g) enabled. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0912171051320.1844>