Date: Wed, 7 Aug 2002 09:07:18 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: mb@imp.ch, deischen@freebsd.org Subject: Re: Help needed. Deadlock in rtld makes openoffice build hang ag Message-ID: <200208071607.g77G7I4v058215@vashon.polstra.com> In-Reply-To: <20020807162811.P58571-100000@levais.imp.ch> References: <20020807162811.P58571-100000@levais.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20020807162811.P58571-100000@levais.imp.ch>, Martin Blapp <mb@imp.ch> wrote: > > And even more : > > Normal operation: > > merging registry "../../../../unxfbsd.pro/ucrdoc/com/sun/star/ > ucb/ChaosContent.urd" under key "UCR" in registry "../../../../ > unxfbsd.pro/ucrdoc/cssucb.db". > _thread_sig_handler() Got signal 27, current thread 0x804f000 > _thread_sig_handler() _thread_kern_in_sched == 0 > _thread_sig_handler() sig == _SCHED_SIGNAL > _thread_sig_handler() _thread_run->sig_defer_count = 0 > _thread_sig_handler() _thread_run->yield_on_sig_undefer = 0 > _thread_sig_handler() called thread_sig_savecontext() > merging registry "../../../../unxfbsd.pro/ucrdoc/com/sun/star/ > > etc ... > > Freaked out: > > merging registry "../../../../unxfbsd.pro/ucrdoc/com/sun/star/ > sdbc/XWarningsSupplier.urd" under key "UCR" in registry > "../../../../unxfbsd.pro/ucrdoc/csssdbc.db". > _thread_sig_handler() Got signal 27, current thread 0x8081c00 > _thread_sig_handler() _thread_kern_in_sched == 0 > _thread_sig_handler() sig == _SCHED_SIGNAL > _thread_sig_handler() _thread_run->sig_defer_count = 0 > _thread_sig_handler() _thread_run->yield_on_sig_undefer = 0 > _thread_sig_handler() called thread_sig_savecontext() > _thread_sig_handler() Got signal 27, current thread 0x804f000 > _thread_sig_handler() _thread_kern_in_sched == 0 > _thread_sig_handler() sig == _SCHED_SIGNAL > _thread_sig_handler() _thread_run->sig_defer_count = 1 > _thread_sig_handler() _thread_run->yield_on_sig_undefer = 0 > _thread_sig_handler() Got signal 27, current thread 0x804f000 > _thread_sig_handler() _thread_kern_in_sched == 0 > _thread_sig_handler() sig == _SCHED_SIGNAL > _thread_sig_handler() _thread_run->sig_defer_count = 1 > _thread_sig_handler() _thread_run->yield_on_sig_undefer = 1 > _thread_sig_handler() Got signal 27, current thread 0x804f000 > _thread_sig_handler() _thread_kern_in_sched == 0 > _thread_sig_handler() sig == _SCHED_SIGNAL > _thread_sig_handler() _thread_run->sig_defer_count = 1 > > etc ... > > Why there is suddenly another thread ? 0x8081c00 has changed > to 0x804f000 ... > > _thread_run->sig_defer_count stays forever 1 .... Hopefully, Daniel will be able to explain this. One possibility: you said the failure happens during exit(). Maybe libc_r blocks thread preemption for a portion of the exit processing. If rtld locking contention occurred in that state, the locks would spin forever just as you have observed. Unfortunately, I haven't thought of a fix yet. :-( John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208071607.g77G7I4v058215>