talloc-2.1.12 issues with library destructor

Lukas Slebodnik lslebodn at redhat.com
Sat Mar 24 21:51:58 UTC 2018


The latest version of libtdb changed handling of releaseing autofree_context.
Previously, it was release with atexit and currently tith library destructor.

However, it caused some crashes in sssd test suite when shuttind down
processes. In one case, there was an abort in krb5 library.

                Stack trace of thread 19667:
                #0  0x00007f2cab91ff6b __GI_raise (libc.so.6)
                #1  0x00007f2cab90a5c1 __GI_abort (libc.so.6)
                #2  0x00007f2cab90a491 __assert_fail_base (libc.so.6)
                #3  0x00007f2cab9186e2 __GI___assert_fail (libc.so.6)
                #4  0x00007f2cb10aaca5 k5_mutex_lock (libkrb5.so.3)
                #5  0x00007f2cb10ab790 k5_mutex_lock (libkrb5.so.3)
                #6  0x00007f2cb10ab8f5 profile_free_file (libkrb5.so.3)
                #7  0x00007f2cb10ab983 profile_close_file (libkrb5.so.3)
                #8  0x00007f2cb10af249 profile_release (libkrb5.so.3)
                #9  0x00007f2cb10a06c7 k5_os_free_context (libkrb5.so.3)
                #10 0x00007f2cb1075a9a krb5_free_context (libkrb5.so.3)
                #11 0x000055cea7cb2dd1 kcm_data_destructor (sssd_kcm)
                #12 0x00007f2cac153e96 _tc_free_internal (libtalloc.so.2)
                #13 0x00007f2cac1537b0 _tc_free_internal (libtalloc.so.2)
                #14 0x00007f2cac1537b0 _tc_free_internal (libtalloc.so.2)
                #15 0x00007f2cac1537b0 _tc_free_internal (libtalloc.so.2)
                #16 0x00007f2cac1537b0 _tc_free_internal (libtalloc.so.2)
                #17 0x00007f2cac14e648 _talloc_free (libtalloc.so.2)
                #18 0x00007f2cac14c480 talloc_lib_fini (libtalloc.so.2)
                #19 0x00007f2cb151da96 _dl_fini (ld-linux-x86-64.so.2)
                #20 0x00007f2cab9226bc __run_exit_handlers (libc.so.6)
                #21 0x00007f2cab9227ec __GI_exit (libc.so.6)
                #22 0x00007f2cb030dc61 orderly_shutdown (libsss_util.so)
                #23 0x00007f2cac365a46 tevent_common_check_signal (libtevent.so.0)
                #24 0x00007f2cac367975 epoll_event_loop_once (libtevent.so.0)
                #25 0x00007f2cac365dab std_event_loop_once (libtevent.so.0)
                #26 0x00007f2cac362098 _tevent_loop_once (libtevent.so.0)
                #27 0x00007f2cac3622eb tevent_common_loop_wait (libtevent.so.0)
                #28 0x00007f2cac365d3b std_event_loop_wait (libtevent.so.0)
                #29 0x00007f2cb030eb37 server_loop (libsss_util.so)
                #30 0x000055cea7cb29f4 main (sssd_kcm)
                #31 0x00007f2cab90c1eb __libc_start_main (libc.so.6)
                #32 0x000055cea7cb2c7a _start (sssd_kcm)

Previously, it was not problem because atexit/on_exit are executed before
destructors. Nice description is in a blog[1].

Another crash is in nss_wrapper(in attachment) because gethostname was called
by libldap which tried to initialize some structures (ldap_int_initialize).
And it is really unexpected that libldap tries to initialize some structures
at exit. I would say it tries to initialize something which was already
released otherwise ldap_int_initialize would not be called

Maybe it could be solved with priority of destructors but documentation
does not say anything about default priority.

I was also not able to find anything about order of destructors between

On the one hand it happens just at shutdown but on the other hand it is
still a crash. Can you see some crashes even with samba? I am not sure
whether you have configured some way to detect crashes which does not cause
failures in autobuild
(systemd-coredumpd ...)


[1] http://ptspts.blogspot.cz/2014/01/how-to-run-custom-code-before-and-after.html
[2] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-destructor-function-attribute

More information about the samba-technical mailing list