#114 OpenDKIM segfaults at shutdown

2.5.2
closed-fixed
opendkim (95)
6
2013-02-25
2012-06-02
No

When issuing a shutdown request, opendkim segfaults. From gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00007f087594b3c4 in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) thr apply all bt

Thread 3 (Thread 0x7f08745d5700 (LWP 15172)):
#0 0x00007f0875951695 in sigwait () from /lib/libpthread.so.0
#1 0x00000000004087ef in dkimf_reloader (vp=0x0) at opendkim.c:5499
#2 0x00007f08759489ca in start_thread () from /lib/libpthread.so.0
#3 0x00007f08756a5cdd in clone () from /lib/libc.so.6
#4 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f0877ae0720 (LWP 15170)):
#0 0x00007f087594b3c4 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x000000000041ed82 in dkimf_crypto_lock_callback (mode=9, idx=12, file=0x7f08765b67be "ssl_lib.c", line=1903) at opendkim-crypto.c:164
#2 0x00007f08761f5a87 in CRYPTO_add_lock (pointer=0x2653644, amount=-1, type=12, file=0x7f08765b67be "ssl_lib.c", line=<value optimized out>) at cryptlib.c:632
#3 0x00007f08765a6bdf in SSL_CTX_free (a=0x26535b0) at ssl_lib.c:1903
#4 0x00007f0876e3ef6a in tlso_ctx_free (ctx=0x26535b0) at tls_o.c:205
#5 0x00007f0876e3c51b in ldap_pvt_tls_ctx_free (c=0x26535b0) at tls2.c:79
#6 0x00007f0876e3c575 in ldap_int_tls_destroy (lo=0x7f08770541a0) at tls2.c:101
#7 0x00007f0876e2f2b0 in ldap_int_destroy_global_options () at init.c:504
#8 0x00007f0876e0bddf in __do_global_dtors_aux () from /opt/zimbra/openldap-2.4.31.5z/lib/libldap-2.4.so.2
#9 0x0000000000000000 in ?? ()

From the messages log:

Jun 1 19:59:48 zre-ldap002 kernel: [986830.056788] opendkim[32292]: segfault at 1f0 ip 00007f4a105b73c4 sp 00007fffbaf3a570 error 4 in libpthread-2.11.1.so[7f4a105ae000+18000]

Discussion

1 2 > >> (Page 1 of 2)
    • labels: --> opendkim
     
  • Note: This is OpenDIM 2.6.0 Beta 4

     
    • milestone: --> 2.5.2
    • assigned_to: nobody --> cm-msk
    • priority: 5 --> 6
     
  • Which version of openssl? The stubs we provide to openssl are crafted based on their examples and have been working fine for years now, so I'm wondering if this might be a bug in their code.

    Try "print nmutexes" from gdb while thread 1 is selected.

     
  • It looks like both openldap and opendkim are setting up their part of openssl multithreading, and they're stepping on each other. In particular, it looks like we might end up trying to manipulate mutexes using opendkim functions although the mutexes are actually owned by openldap.

    I'm not sure what the right solution here would be. It might be as simple as being able to tell opendkim not to do this setup, but that feels wrong because opendkim is an application while openldap is a library, so it really should be opendkim making these arrangements and not a library.

    Is there an openldap flag to tell it not to do the crypto mutex setup?

     
    • priority: 6 --> 5
     
    • assigned_to: cm-msk --> nobody
     
    • priority: 5 --> 6
     
    • assigned_to: nobody --> cm-msk
     
1 2 > >> (Page 1 of 2)