Page MenuHome GnuPG

Use of atexit() problematical for dynamically loaded libraries -- libgpg-error
Closed, ResolvedPublic

Description

Libgpg-error may end up being dynamically loaded, either directly
or perhaps more commonly indirectly, via use of e.g. dlopen().

Some programs will subsequently do dlclose() before calling exit().
In this context, use of atexit() to register an in-library function
for invocation at exit() time is problematical, and will in all
probability cause a segmentation fault. It does in my case, running
this on NetBSD/amd64 6.1.5.

I was told that use of attribute((destructor,used)) is probably
a better way of dealing with this, as it will cause the marked function
to be called both on dlclose() and it remains present at exit().

The attached patch has been added to NetBSD's pkgsrc to effect this change.

Details

Version
1.15 & 1.17

Event Timeline

BTW, the segmentation faults have been observed
with apache and "stand-alone" php.

All kind of problems may appear if you dlopen libgpg-error. It is possible to
do this on Windows due to the very different architecture but Unix/ELF is too
limited to work correctly. The bug you see is just one on the surface - tehre
are lot of other problems below the surface.

In short: Do not dlopen libgpg-error.

You better link apache with libgpg-error so that other dlopen stuff may use the
already loaded code.

Hm, the suggestion of linking with libgpg-error doesn't really
scale -- think in terms of someone providing pre-built binaries
for e.g. apache and/or php. Where does it end? Should these
programs be linked with all potential otherwise loadable modules?
Why should libgpg-error be special in this regard?

Also, doesn't using atexit() make this problem far worse?
Perhaps libgpg-error can stop doing that, at least?

No we can't stop doing that. The cleanup function is required to flush the
internal buffers. atexit is a standard C function - dlopen is only a sometimes
useful kludge.

werner claimed this task.
werner added a project: Won't Fix.