perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
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.

right

>>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:
http://marc.theaimsgroup.com/?l=perl5-porters&m=110548418315028&w=2

>>>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
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message