You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Christian Gross <Ch...@yahoo.de> on 2001/05/25 05:33:26 UTC
BUG???? Locks and never released
Hi
I was playing around with the locks and noticed that if I allocate a
lock and then acquire it it will not be released and destroyed
automatically.
What I saw was that the memory pool from where the lock was allocated
gets yanked even though the program may still have a reference to the
lock. This could cause a program to creash.
Is this a bug? Or am I missing something?
Christian
Re: BUG???? Locks and never released
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> Win32 seems to be missing a apr_pool_cleanup_register() call. I think
> something along the lines of the following might work, but I don't know.
> -- justin
>
> Index: locks/win32/locks.c
> ===================================================================
> RCS file: /home/cvspublic/apr/locks/win32/locks.c,v
> retrieving revision 1.36
> diff -u -r1.36 locks.c
> --- locks/win32/locks.c 2001/02/16 04:15:56 1.36
> +++ locks/win32/locks.c 2001/05/25 15:16:04
> @@ -91,6 +91,8 @@
> newlock->mutex = CreateMutex(&sec, FALSE, fname);
> }
> *lock = newlock;
> + apr_pool_cleanup_register(newlock->cntxt,(void*)new, apr_lock_destroy,
> + apr_pool_cleanup_null);
> return APR_SUCCESS;
> }
I just committed something along the same lines but with a couple of
tweaks:
1) apr_lock_destroy() has the wrong signature for a cleanup routine
2) the cleanup needs to be removed when the lock is destroyed
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: BUG???? Locks and never released
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, May 24, 2001 at 11:33:26PM -0400, Christian Gross wrote:
> Hi
>
> I was playing around with the locks and noticed that if I allocate a
> lock and then acquire it it will not be released and destroyed
> automatically.
>
> What I saw was that the memory pool from where the lock was allocated
> gets yanked even though the program may still have a reference to the
> lock. This could cause a program to creash.
>
> Is this a bug? Or am I missing something?
Win32 seems to be missing a apr_pool_cleanup_register() call. I think
something along the lines of the following might work, but I don't know.
-- justin
Index: locks/win32/locks.c
===================================================================
RCS file: /home/cvspublic/apr/locks/win32/locks.c,v
retrieving revision 1.36
diff -u -r1.36 locks.c
--- locks/win32/locks.c 2001/02/16 04:15:56 1.36
+++ locks/win32/locks.c 2001/05/25 15:16:04
@@ -91,6 +91,8 @@
newlock->mutex = CreateMutex(&sec, FALSE, fname);
}
*lock = newlock;
+ apr_pool_cleanup_register(newlock->cntxt,(void*)new, apr_lock_destroy,
+ apr_pool_cleanup_null);
return APR_SUCCESS;
}