This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/18136] Different semantics between atexit and destructor functions
- From: "philipp.waehnert at posteo dot de" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 18 Mar 2015 09:11:36 +0000
- Subject: [Bug libc/18136] Different semantics between atexit and destructor functions
- Auto-submitted: auto-generated
- References: <bug-18136-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18136
--- Comment #3 from philipp.waehnert at posteo dot de ---
Concerning the backtraces these three approaches are very similar:
__attribute__((destructor)):
#0 close_plugin (p=0x7ffff7632040) at framework.c:11
#1 0x00007ffff7deb0ea in _dl_fini () at dl-fini.c:252
#2 0x00007ffff786cca9 in __run_exit_handlers (status=0,
listp=0x7ffff7bd25a8 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#3 0x00007ffff786ccf5 in __GI_exit (status=<optimized out>) at exit.c:104
#4 0x00007ffff7856a6c in __libc_start_main (main=0x40069d <main>, argc=1,
argv=0x7fffffffdf78, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdf68) at libc-start.c:319
#5 0x00000000004005d9 in _start ()
atexit():
#0 close_plugin () at framework.c:11
#1 0x00007ffff786cca9 in __run_exit_handlers (status=0,
listp=0x7ffff7bd25a8 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#2 0x00007ffff786ccf5 in __GI_exit (status=<optimized out>) at exit.c:104
#3 0x00007ffff7856a6c in __libc_start_main (main=0x40069d <main>, argc=1,
argv=0x7fffffffdf78, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdf68) at libc-start.c:319
#4 0x00000000004005d9 in _start ()
__cxa_atexit():
#0 close_plugin (p=0x602030) at framework.c:11
#1 0x00007ffff786cca9 in __run_exit_handlers (status=0,
listp=0x7ffff7bd25a8 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#2 0x00007ffff786ccf5 in __GI_exit (status=<optimized out>) at exit.c:104
#3 0x00007ffff7856a6c in __libc_start_main (main=0x40069d <main>, argc=1,
argv=0x7fffffffdf78, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdf68) at libc-start.c:319
#4 0x00000000004005d9 in _start ()
The first one has this extra call to _dl_fini() and this makes exactly the
difference.
I agree, it seems to be a bad idea to unload dynamically loaded libraries
inside such functions. It would be better, if libframework.so exposed
close_plugin() and the client is in charge to remind libframework.so to clean
up. But my problem stems from a historically grown code base and under C++
these flawed approaches seem way more natural: The same situation arises if the
class loading the plugins is a singleton and unloads them in its destructor.
--
You are receiving this mail because:
You are on the CC list for the bug.