perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded
Date Wed, 12 Jan 2005 15:38:36 GMT
Gurusamy Sarathy wrote:
> On Tue, 11 Jan 2005 20:32:13 EST, Stas Bekman wrote:
>>Gurusamy Sarathy wrote:
>>>On Tue, 11 Jan 2005 14:55:12 EST, Stas Bekman wrote:
>>>>+++ src/modules/perl/mod_perl.c (working copy)
>>>>@@ -573,6 +573,17 @@
>>>>    MP_threads_started = 0;
>>>>    MP_post_post_config_phase = 0;
>>>>+    /* with USE_ITHREADS perl leaks pthread_key_t on every
>>>>+     * perl_destruct, which becomes a problem restarts: if the OS
>>>This is not a leak, that's how it is supposed to work.
>>How can you say that it's not a leak,
> What I meant was that the pthread key is normally supposed to stay
> allocated even after a perl_destruct() (your comment implied
> otherwise).
>>if perl allocates the key again and again.
> Perl doesn't _want_ to allocate the key again and again--this
> is why the PL_curinterp check exists.  The fact that PL_curinterp
> is getting reset to NULL when that global lives in a shared object
> that gets reloaded is the real source of the bug.


>>mod_perl doesn't do anything forbidden, just calls 
>>perl_(alloc|parse|destruct|free). It's just that until now the problem was 
>>hidden. Any embed app that has to restart will have exactly the same problem.
>>>A pthread_key_t gets allocated for the lifetime of a process
>>>or for the duration a shared library remains loaded.  It is not
>>>something that is local to a single perl interpreter as the
>>>comment above seems to imply.
>>Jan and Gisle have already explained that to me :) It was just an old 
>>version of the comment I forgot to adjust.
> Sorry, I probably did not manage to read all of the thread before
> pitching in.
>>I agree, but I just try to provide a workaround for the bug in perl. I 
>>can't do any ref counting on behalf of perl.
> But the workaround is not entirely harmless.  Gisle's fix is
> certainly better, so why not include that within mod_perl?

If you look at my latest patch, it's exactly that:

>>>An even better approach might be to make Perl use pthread_once()
>>>to allocate its perl_key instead of relying on PL_curinterp being
>>>a never-NULL variable.  Doing this might actually make Gisle's
>>>fix unnecessary.  This will also probably make it unnecessary to
>>>call pthread_key_delete() anywhere.
>>Sounds like an excellent idea to me.
> On second thought, that idea won't fly without convolutions that
> aren't needed by Gisle's patch, because PL_thr_key is "forgotton"
> when the shared object is reloaded (PL_thr_key suffers the same
> fate as PL_curinterp because both live in the same shared object).
> So to make that approach work, you'd need to remember/restore
> PL_thr_key when the shared object is unloaded/reloaded.

Yes, you are again correct, Gurusamy.

> So I think Gisle's patch is in fact the simpler/more elegant fix
> here.

Unfortunately it's not portable (talking about inclusion on perl-core).

> I think mod_perl could also consider avoiding the unloading
> of the perl code to avoid this problem.  IOW, whichever shared
> object contains these perl globals is never dlclose()d for the
> lifetime of the process.

No, thank you, mod_perl1 does something similar and it's a cause of 
various unresolved memory leaks on certain platform, where apparently the 
non-unloading doesn't work quite well.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message