Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 70222 invoked from network); 25 Sep 2003 00:23:03 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 25 Sep 2003 00:23:03 -0000 Received: (qmail 25835 invoked by uid 500); 25 Sep 2003 00:22:46 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 25800 invoked by uid 500); 25 Sep 2003 00:22:45 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 25786 invoked from network); 25 Sep 2003 00:22:45 -0000 Message-ID: <3F72355A.1000800@stason.org> Date: Wed, 24 Sep 2003 17:22:50 -0700 From: Stas Bekman Organization: Hope, Humanized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Blair Zajac Cc: dev@apr.apache.org Subject: Re: segfault in apr_atomic_cas References: <3F721608.2030708@stason.org> <3F723195.8983E6E9@orcaware.com> In-Reply-To: <3F723195.8983E6E9@orcaware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Blair Zajac wrote: > Stas Bekman wrote: > >>When using apr built with --enable-pool-debug=all I get this segfault on the >>httpd server startup: >> >>#0 0x4026cbe4 in apr_atomic_cas () >> from /home/stas/httpd/prefork/lib/libapr-0.so.0 >>(gdb) where >>#0 0x4026cbe4 in apr_atomic_cas () >> from /home/stas/httpd/prefork/lib/libapr-0.so.0 >>#1 0x40268b2d in apr_thread_mutex_lock () >> from /home/stas/httpd/prefork/lib/libapr-0.so.0 >>#2 0x4026b77e in apr_pool_create_ex_debug () >> from /home/stas/httpd/prefork/lib/libapr-0.so.0 >>#3 0x40267685 in apr_initialize () >> from /home/stas/httpd/prefork/lib/libapr-0.so.0 >>#4 0x40267618 in apr_app_initialize () >> from /home/stas/httpd/prefork/lib/libapr-0.so.0 >>#5 0x080c6fb8 in main (argc=2, argv=0xbffff4e4) at main.c:426 >>#6 0x40352c57 in __libc_start_main () from /lib/i686/libc.so.6 >> >>This happens because hash_mutex[] is not initialized when apr_pool_create is >>called. >> >>The apr_atomic_init that initializes that variable is running too late: >> >> if (apr_pool_create(&pool, NULL) != APR_SUCCESS) { >> return APR_ENOPOOL; >> } >> >> apr_pool_tag(pool, "apr_initialize"); >> >> if ((status = apr_atomic_init(pool)) != APR_SUCCESS) { >> return status; >> } > > > Yes, I brought this up a month ago. > > See the thread with the subject > > "unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump" > > Sander responded there, but there's been no work on it yet. I hoped that I'll never need to do that, so I was ignoring any threads on that subject. Now we have several problems with pools that I need to debug before I can report them. I have a dirty workaround, setting global_pool->mutex to NULL, at least I can do some debugging. __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com