This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bug with dlclose and static class elements


Andreas Schwab <schwab@issan.informatik.uni-dortmund.de> writes:

> Harald Hoyer <Harald.Hoyer@hot.spotline.de> writes:
> 
> |> Hi,
> |> 
> |> the attached tarball demonstrates the failure of deleting static elements in
> |> classes, if the library that contains these class is unloaded with dlclose.
> |> 
> |> My question is whether this is a glibc (libdl) bug or a bug in generating the
> |> code (egcs).
> 
> IMHO this is a bug in gcc.  It should not use atexit to register the dtor
> for static local objects.  Instead it should set up an entry in the .dtors
> section.  There is no (standard) way to unregister an atexit function, and
> implementing it would require to put a hook into libc for use by the
> dynamic linker.
> 
> [For the readers of the egcs list: the full report is available under
> http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/938]

The following patch will fix egcs 1.1b (applies cleanly) and 1.1.1
(applies with fuzz). I still need to send it to the egcs maintainers,
but I want to batch it with an other fix.

How it works: instead of calling atexit() when the function's statis
is initialized the first time, some code is generated in .FINI which
calls the destructor iff the static has been initialized.
Pretty straightforward patch.

Phil.

egcs-1_1b.patch.gz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]