Re: xmlRMutexLock deadlock?
Torsten Förtsch <[email protected]>
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Message-ID | <[email protected]> |
On Monday, 28 May 2012 14:31:40 Kogelheide, Ryan LCTZ:EX wrote:
> Apache 2.0.64 using worker/pthreads on Solaris 10
> mod_perl-2.0.4
this is quite old stuff.
> I recently installed a new release of an application developed by another
> team member. It locked up our apache instances as soon as they came under
> load.
>
> pstack showed that all the Apache HTTPD server processes have all
> lwp/threads stuck in
>
> modperl_tipool_pop
> modperl_interp_get
> modperl_interp_select
> modperl_response_handler_cgi
looks like you ran out of perl interpreters. When all configured interpreters
are in use every subsequent request that needs an interpreter will stop here.
See
http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives
> except one that's stuck in
>
> cond_wait_queue
> cond_wait
> pthread_cond_wait
> pthread_cond_wait
> xmlRMutexLock
> xmlCatalogCleanup
> xmlCleanupParser
> XS_XML__LibXML_END
> Perl_pp_entersub
> Perl_call_sv
> modperl_perl_call_list
> modperl_perl_call_endav
> modperl_perl_destruct
This looks like an END{} block out of XML::LibXML being executed when an
interpreter is shut down. What it waits for here I don't know.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net