This is the mail archive of the glibc-bugs@sourceware.org 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]
Other format: [Raw text]

[Bug libc/18136] Different semantics between atexit and destructor functions


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.


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