Full_Name: hark Version: commit 9773f43b11aa8fac51407694bbdcd17830f206d5 OS: debian 9.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.169.146.71) openldap is build with: CFLAGS='-g' ./configure --enable-debug --enable-perl --enable-modules --enable-passwd LTCFLAGS='-g' export LTCFLAGS make depend make mkdir /root/openldapdebug/ make install STRIP='' DESTDIR='/root/openldapdebug' started with: gdb --args /root/openldapdebug/usr/local/libexec/slapd -d1 -h "ldap:/// ldapi:///var/run/slapd/ldapi" -F /etc/ldap/slapd.d then when trying to do: ldapadd -x -w $PW -D cn=admin,cn=config -H ldap:"F2F -f /root/src/ldapcrash/slapd-add-perl.ldif cat slapd-add-perl.ldif dn: olcDatabase=perl,cn=config objectClass: olcDatabaseConfig objectClass: olcDbPerlConfig olcDatabase: perl olcSuffix: dc=perl-example,dc=com olcPerlModulePath: /root/src/perlldap/ olcPerlModule: SampleLDAP olcPerlFilterSearchResults: FALSE #olcPerlModuleConfig: something dn: dc=perl-example,dc=com objectClass: top objectClass: dcObject objectClass: organizationalUnit dc: perl-example ou: perl-example-ou it crashes: 58a4ca92 >>> dnNormalize: <olcDatabase={2}perl> 58a4ca92 <<< dnNormalize: <olcDatabase={2}perl> 58a4ca92 >>> dnPrettyNormal: <dc=perl-example,dc=com> 58a4ca92 <<< dnPrettyNormal: <dc=perl-example,dc=com>, <dc=perl-example,dc=com> 58a4ca92 perl backend db init Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to LWP 7204] 0x00006a7b721f64f3 in ?? () (gdb) bt #0 0x00006a7b721f64f3 in ?? () #1 0x00006a7b721a23af in ?? () #2 0x000003ad6f16fd18 in ?? () #3 0x000003ad6f16fd48 in ?? () #4 0x000003ad00000018 in ?? () #5 0x00006a7b2d663930 in ?? () #6 0x00006a7b2d6638c0 in ?? () #7 0xb0ac74c0fb38d600 in ?? () #8 0x000003ad6f16fd48 in ?? () #9 0x000003ad6f16fd48 in ?? () #10 0x0000000000000000 in ?? () When trying that multiple times, the backtraces are different: Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to LWP 7258] 0x00007cd6f62984f3 in ?? () (gdb) bt #0 0x00007cd6f62984f3 in ?? () #1 0x00007cd6f62443af in ?? () #2 0x00000229299536c8 in ?? () #3 0x00000229299536f8 in ?? () #4 0x0000022900000018 in ?? () #5 0x00007cd6b16e4930 in ?? () #6 0x00007cd6b16e48c0 in ?? () #7 0x5c084850684a2100 in ?? () #8 0x00000229299536f8 in ?? () #9 0x00000229299536fin % ?? () #10 0x0000000000000000 in ?? () [Switching to LWP 7270] 0x00006adbabc534f3 in ?? () (gdb) bt #0 0x00006adbabc534f3 in ?? () #1 0x00006adbabbff3af in ?? () #2 0x00000442aef9d2c8 in ?? () #3 0x00000442aef9d2f8 in ?? () #4 0x0000044200000018 in ?? () #5 0x00006adb670f3930 in ?? () #6 0x00006adb670f38c0 in ?? () #7 0x918aaeeca7964a00 in ?? () #8 0x00000442aef9d2f8 in ?? () #9 0x00000442aef9d2f8 in ?? () #10 0x0000000000000000 in ?? () perl --version This is perl 5, version 24, subversion 1 (v5.24.1) built for x86_64-linux-gnu-thread-multi (with 63 registered patches, see perl -V for more detail)
moved from Incoming to Software Bugs
Created attachment 720 [details] backtrace Reproduced on Debian unstable (sid) with OpenLDAP 2.4.49 and Perl 5.30. Attaching a better backtrace. I note that it doesn't happen every time, sometimes it does start up fine. So the crash is here: https://sources.debian.org/src/perl/5.30.0-10/util.c/#L5415 (gdb) p my_perl $1 = (PerlInterpreter *) 0x0 (gdb) p &my_perl->Ixsubfilename $2 = (const char **) 0x5d8 When it doesn't crash, my_perl is equal to PL_curinterp. (gdb) p my_perl $1 = (PerlInterpreter *) 0x7fffa8106560 (gdb) p PL_curinterp $2 = (PerlInterpreter *) 0x7fffa8106560 (gdb) p my_perl == PL_curinterp $3 = 1 my_perl seems to come from Perl_get_context(): https://sources.debian.org/src/perl/5.30.0-10/util.c/?hl=3339#L3339 The corresponding pthread_setspecific() happens inside perl_back_initialize. #0 __GI___pthread_setspecific (key=3, value=value@entry=0x7fffa8106560) at pthread_setspecific.c:33 #1 0x00007fffb5aac68e in S_init_tls_and_interp (my_perl=0x7fffa8106560) at perl.c:92 #2 perl_alloc () at perl.c:200 #3 0x00007ffff71aa70a in perl_back_initialize (bi=0x7ffff71b1220 <bi>) Later, Perl_eval_pv invokes a DynaLoader to load the eval'ed code. This module's startup is where Perl_xs_handshake is called, to check for compatibility between the library's global Perl context (Perl_get_context()) and the one passed in from the application (implicit argument to Perl_eval_pv()). Normally these would just be the same. Anyway, this looks like a pretty simple bug in back_perl: we're just missing a PERL_SET_CONTEXT() in perl_cf(), so it crashes if called from a different thread than perl_back_initialize(). We should audit and make sure every back_perl entry point calls it.
*** This issue has been marked as a duplicate of issue 7573 ***