develooper Front page | perl.perl5.porters | Postings from August 2013

[perl #2968] dl_unload_all_files() revisited

Thread Previous | Thread Next
From:
Tony Cook via RT
Date:
August 9, 2013 07:35
Subject:
[perl #2968] dl_unload_all_files() revisited
Message ID:
rt-3.6.HEAD-2552-1376033740-231.2968-15-0@perl.org
On Fri May 04 08:52:57 2012, Hugmeir wrote:
> On Sun Apr 02 22:51:44 2000, RT_System wrote:
> > On Sun, Apr 02, 2000 at 11:05:41AM +0100, Alan Burlison wrote:
> > > My current understanding is that this patch broke DBD::Oracle on
Linux -
> > > I'm not quite sure why.
> > 
> > I'll happily help as far as I can if you send me details.
> > 
> > (Oracle does very weird things with it's libraries, and then does
> > different weird things in the following release).
> > 
> > > I can see a potential problem if a module uses
> > > call_atexit(), and that then uses a bit of XS that has already been
> > > dlclosed, but for DBD::Oracle this doesn't seem to be the case.
> > > 
> > > I (respectfully!) disagree with Sarathay's assertion that dlclosing()
> > > stuff when the interpreter exits is an 'unnecessary overhead' - it
is an
> > > *essential* part of the cleanup, much in the same way as freeing up
> > > everything that has been malloced is.  It is alright to not free
and not
> > > dlclose if you know that the process is going to exit anyway, but
in the
> > > case of an embedded perl interpreter this is not necessarily the case.
> > 
> > I think Sarathy meant it's an 'unnecessary overhead' when _not_
embedding.
> > 
> > > I'd like to get the dlclose stuff into a state where it on by default,
> > 
> > When embedding, yes.
> > 
> > > as not having it there generates a particulary abstruse type of
bug - it
> > > took the best part of a year to figure out why mod_perl dumped
core when
> > > built with APXS.
> > > 
> > > I'd like some informed suggestions of the best way of doing this
> > > whithout causing collateral damage - anyone have any ideas?
> > 
> > Do dl_unload_all_files() if Perl_destruct_level > 0.
> > 
> > Tim.
> > 
> 
> I can't find the context behind this report. There.. seems to be a
> solution for the poster's issue at the end, but does anyone know if this
> is still an issue?
> 
> Does anyone know what the issue _was_? : /

From reading the thread, apparently we (were|are) not releasing loaded
shared libraries when we clean up the interpreter.

This isn't a problem when perl is running standalone, but is a problem
when perl is embedded, since we're continuing to use resources after the
interpreter has been deleted.

As to the proposed solution, I wonder if freeing the libraries on
interpreter destruction is safe - it should be sort-of-safe where the
underlying library management tools reference count shared libraries
(true for dlopen and MSWin32), but I don't think it's safe otherwise.

Also, there doesn't seem to be an XS entry point (like boot_Foo for
module Foo) to do clean up for a loaded XS module, which means memory
may leak anyway (and other worse things, like dangling signal handlers.)

Tony

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=2968

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About