apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Lewallen <jlewa...@cs.ucr.edu>
Subject Re: unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump
Date Thu, 21 Aug 2003 22:00:59 GMT
Blair Zajac wrote:
> I tracked my core dump down to the following combination.

   I also have had problems with pool debugging and multithreaded APR 
applications. I've attached an e-mail I sent with a few months ago 
detailing my problems. It'd be nice to get these things cleaned up, they 
seem a tad bit related. I looked over the changes made from 1.18 to 1.19 
and there seems to have been some changes to how the mutex ownership was 
manipulated, which, again, is something that the pools debugging code 
doesn't handle correctly itself at the moment. It appears this patch 
I've attached may not handle everything, but it's at least a starting 
point and goes to the heart of the problem that I've experienced with 
pool debugging. Perhaps someone more familar with thread_mutex.c and 
take a look and see if Blair's problem is related?

> 
> BTW, I'm using --enable-pool-debug=yes with APR as part of
> Subversion.
> 


     This is in reference to my previous e-mail regarding Solaris and an 
EOF when reading from apr_proc_create'd processes. I narrowed this down 
to another problem I had experienced with apr_thread_exit.

There are a few places where we're doing things to pools from threads 
who don't "own" the given pool, thereby causing the 
apr_pool_check_integrity to fail horrible when debugging. For example, 
in apr_thread_exit (we call apr_pool_destroy on the pool we created in 
apr_pool_create) Another example is in apr_proc_create, where we call 
apr_pool_cleanup_kill to remove some apr_file_t cleanups.

I checked the docs and at one point there seemed to have been the desire 
to include an apr_pool_owner_set (just grep, it's only mentioned once in 
the source) So here's a patch that implements the apr_pool_owner_set 
function and places calls to fix the above mentioned problems. The 
reason for the EOF was such that the child process would simply abort 
(with no messages because stdout and such had been redirected) Things 
worked fine under Linux because of the way thread ID's are assigned, I 
would guess. Fire away.

-- 
jacob lewallen
jlewalle@cs.ucr.edu

Mime
View raw message