(ITS#8414) test008 is non portable due to use of "time" command
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.44
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
test008 uses the "time" command as part of the test script. However, that is
not portable as the default /bin/sh shell on Debian and Ubuntu does not have
"time" as a built-in. "time" is only present there for debugging, and is not
required for the test itself. Time to remove time.
7 years, 5 months
Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by hyc＠symas.com
nivanova(a)symas.com wrote:
> Full_Name: Nadezhda Ivanova
> Version: 2.5
> OS: Ubuntu 14.04
> URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch
> Submission from: (NULL) (78.83.54.234)
>
>
> The problem was reproduced when attempting to modify the dynamic configuration
> of meta and asyncmeta rewrite engine. On a meta database that has rewrite
> enabled and some rewrite rules configured, execute ldapmodify with the following
> LDIF:
> dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config
> replace: olcDbRewrite
> olcDbRewrite: rewriteEngine "off"
Hm, multiple problems with this patch:
> diff --git a/servers/slapd/back-asyncmeta/config.c b/servers/slapd/back-asyncmeta/config.c
> index 1801a55..a4fbb91 100644
> --- a/servers/slapd/back-asyncmeta/config.c
> +++ b/servers/slapd/back-asyncmeta/config.c
> @@ -1797,14 +1797,66 @@ asyncmeta_back_cf_gen( ConfigArgs *c )
>
> case LDAP_BACK_CFG_SUFFIXM: /* unused */
> case LDAP_BACK_CFG_REWRITE:
> - if ( mt->mt_rwmap.rwm_bva_rewrite ) {
> - ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite );
> - mt->mt_rwmap.rwm_bva_rewrite = NULL;
> - }
> - if ( mt->mt_rwmap.rwm_rw )
> + {
> + char *argv0;
> + if ( c->valx >= 0 ) {
> + int i;
> +
> + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ )
Need a semicolon for the empty for-loop. Or, if it's intended that the
following if-block is part of the loop, it needs to be properly enclosed in
braces and indented.
> +
> + if ( c->valx >= i ) {
> + rc = 1;
> + break;
> + }
> + ber_memfree( mt->mt_rwmap.rwm_bva_rewrite[ c->valx ].bv_val );
> + for ( i = c->valx; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ] ); i++ )
> + {
> + mt->mt_rwmap.rwm_bva_rewrite[ i ] = mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ];
> + }
> + BER_BVZERO( &mt->mt_rwmap.rwm_bva_rewrite[ i ] );
> +
> rewrite_info_delete( &mt->mt_rwmap.rwm_rw );
> - break;
> + assert( mt->mt_rwmap.rwm_rw == NULL );
> +
> + rc = asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw );
> +
> + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ )
> + {
> + ConfigArgs ca = { 0 };
> +
> + ca.line = mt->mt_rwmap.rwm_bva_rewrite[ i ].bv_val;
> + ca.argc = 0;
Unnecessary initialization, you already set all of ca = {0}.
> + init_config_argv( &ca );
> + config_parse_ldif( &ca );
> +
> + argv0 = ca.argv[ 0 ];
What is argv0 being saved for?
> + if ( !strcasecmp( ca.argv[0], "suffixmassage" )) {
> + rc = asyncmeta_suffixm_config( &ca, ca.argc, ca.argv, mt );
> + } else {
> + rc = rewrite_parse( mt->mt_rwmap.rwm_rw,
> + c->fname, c->lineno, ca.argc, ca.argv );
> + }
> +
> + ca.argv[ 0 ] = argv0;
Why is argv0 being restored? All you're doing after this is freeing ca.argv
anyway.
> +
> + ch_free( ca.tline );
> + ch_free( ca.argv );
>
> + assert( rc == 0 );
> + }
> +
> + } else if ( mt->mt_rwmap.rwm_rw != NULL ) {
> + if ( mt->mt_rwmap.rwm_bva_rewrite ) {
> + ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite );
> + mt->mt_rwmap.rwm_bva_rewrite = NULL;
> + }
> + if ( mt->mt_rwmap.rwm_rw )
> + rewrite_info_delete( &mt->mt_rwmap.rwm_rw );
> +
> + asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw );
> + }
> + }
> + break;
> case LDAP_BACK_CFG_MAP:
> if ( mt->mt_rwmap.rwm_bva_map ) {
> ber_bvarray_free( mt->mt_rwmap.rwm_bva_map );
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
(ITS#8413) Assertion in back-mdb/search.c during replication
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.44
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
During replication from the accesslog DB, in a 4-way MMR setup, various masters
periodically crash with slapd: search.c:1246: oc_filter: Assertion `f != ((void
*)0)' failed.
This is back-mdb/search.c, not slapd-search.c
This is triggered when a NULL filter is passed through. However, it should be
impossible for the filter generated by str2filter to ever fail.
7 years, 5 months
Re: (ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by hyc＠symas.com
lukaswhl(a)gmail.com wrote:
> Full_Name: Lukas W
> Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2407:7000:9a07:8600::2)
>
>
> The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is
> inconsistent with those of other OPs. For instance, MDB_NEXT does not change the
> cursor's position, as this was already done by mdb_cursor_del. As far as I
> understand, mdb_cursor_get can be expected to behave just like usual, whether
> mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra
> checks when e.g. removing particular items in a loop based on some criterion (as
> described and discussed in
> http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and
> follow-ups).
>
> However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the
> following three items:
>
> #1: "a" --> 1
> #2: "b" --> 1
> #3: 2b2b" --> 2
>
> Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1
> is removed and the cursor points to #2 (though this is not documented anywhere).
> We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return
> MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it
> would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is
> returned, making anyone who's unaware of this behaviour believe that there's
> another item with the key "a". In my particular case, this leads to #2 being
> deleted as well, even though I only expected to touch items with the key "a",
> which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place.
> In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del
> call, even though one would expect it not to jump across "key boundaries".
>
> On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406
> this would have resulted in an assertion failure.
>
> You could classify this as a bug and adjust the behaviour to match MDB_NEXT's,
> or you could document the behaviour of mdb_cursor_del regarding the cursor's
> state. Either would be appreciated.
Fixed in mdb.master
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
(ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by lukaswhl＠gmail.com
Full_Name: Lukas W
Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2407:7000:9a07:8600::2)
The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is
inconsistent with those of other OPs. For instance, MDB_NEXT does not change the
cursor's position, as this was already done by mdb_cursor_del. As far as I
understand, mdb_cursor_get can be expected to behave just like usual, whether
mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra
checks when e.g. removing particular items in a loop based on some criterion (as
described and discussed in
http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and
follow-ups).
However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the
following three items:
#1: "a" --> 1
#2: "b" --> 1
#3: 2b2b" --> 2
Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1
is removed and the cursor points to #2 (though this is not documented anywhere).
We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return
MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it
would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is
returned, making anyone who's unaware of this behaviour believe that there's
another item with the key "a". In my particular case, this leads to #2 being
deleted as well, even though I only expected to touch items with the key "a",
which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place.
In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del
call, even though one would expect it not to jump across "key boundaries".
On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406
this would have resulted in an assertion failure.
You could classify this as a bug and adjust the behaviour to match MDB_NEXT's,
or you could document the behaviour of mdb_cursor_del regarding the cursor's
state. Either would be appreciated.
7 years, 5 months
Re: (ITS#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com
Thank you. Yes. I recompiled sha2 module for 2.4.44, and it works.
On Sun, Apr 24, 2016 at 8:00 AM, Howard Chu <hyc(a)symas.com> wrote:
> This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2
> password module in your installation. Closing this ITS.
>
>
> Michael Martinez wrote:
>>
>> OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l
>> GNU/Linux
>>
>> (gdb) info shared
>>>
>>> From To Syms Read Shared Object Library
>>
>> 0xb6f344b8 0xb6f35a10 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
>> 0xb6f16c04 0xb6f1b0bc Yes (*)
>> /usr/lib/arm-linux-gnueabihf/libltdl.so.7
>> 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2
>> 0xb6de0dd0 0xb6ee4b74 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/libdb-5.1.so
>> 0xb6da6558 0xb6db7504 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/libsasl2.so.2
>> 0xb6d5f610 0xb6d90bac Yes (*)
>> /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0
>> 0xb6c35e80 0xb6d071c0 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
>> 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1
>> 0xb6ba6444 0xb6bb273c Yes (*)
>> /lib/arm-linux-gnueabihf/libresolv.so.2
>> 0xb6b88eb0 0xb6b9691c Yes (*)
>> /lib/arm-linux-gnueabihf/libpthread.so.0
>> 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6
>> 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3
>> 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1
>> 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1
>> 0xb6f25268 0xb6f298e0 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so
>> 0xb69ced8c 0xb69d0ae0 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so
>> 0xb69c107c 0xb69c3bbc Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so
>> 0xb69ad400 0xb69b59e4 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so
>> 0xb699fe04 0xb69a2004 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so
>> 0xb6993d5c 0xb69957f0 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so
>> 0xb6987d50 0xb6989974 Yes (*)
>> /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so
>> 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so
>> (*): Shared library is missing debugging information.
>>
>> (gdb) bt
>> #0 0xb6f350a0 in memcpy () from
>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
>> #1 0xb6c3f344 in SHA256_Update ()
>> from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
>> #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20,
>> cred=0x1a53468,
>> text=0xa11cab98) at slapd-sha2.c:256
>> #3 0x00121f58 in lutil_passwd ()
>> #4 0x0006ec98 in slap_passwd_check ()
>> #5 0x000e4db8 in bdb_bind ()
>> #6 0x0005bbdc in fe_op_bind ()
>> #7 0x0005b568 in do_bind ()
>> #8 0x000403b8 in ?? ()
>> Cannot access memory at address 0x0
>> #9 0x000403b8 in ?? ()
>> Cannot access memory at address 0x0
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>
>> On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote:
>>>
>>> mwtzzz(a)gmail.com wrote:
>>>>
>>>>
>>>> Full_Name: Michael Martinez
>>>> Version: 2.4.44
>>>> OS: ubuntu wheezy
>>>
>>>
>>>
>>> There is no such OS.
>>>
>>>> URL:
>>>> Submission from: (NULL) (99.113.34.53)
>>>>
>>>>
>>>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults
>>>> anytime I
>>>> run 'passwd', attempt to ssh into the box, etc.
>>>>
>>>> this is on raspberry pi (debian wheezy).
>>>>
>>>> Previously running the latest package 2.4.31. Then installed
>>>> openldap-2.4.44
>>>> from source, did slapcat from the old version and slapadd to import it
>>>> to
>>>> the
>>>> new version. Loads fine and can run simple commands like "id" for ldap
>>>> users.
>>>> But get core dump with password changes, ssh from other boxes, etc.
>>>> A%A[Thread debugging using libthread_db enabled]
>>>> Using host libthread_db library
>>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>>> Core was generated by `/usr/local/openldap/libexec/slapd -f
>>>> /etc/ldap/slapd.conf
>>>> -F /ec/ldap/slapd.d'.
>>>> Program terminated with signal 11, Segmentation fault.
>>>> #0 0xb6f350a0 in memcpy () from
>>>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
>>>> (gdb)
>>>
>>>
>>>
>>> Please provide the full stack trace.
>>>
>>> Also output from "info shared".
>>>
>>> --
>>> -- Howard Chu
>>> CTO, Symas Corp. http://www.symas.com
>>> Director, Highland Sun http://highlandsun.com/hyc/
>>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>>
>>
>>
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
---
Michael Martinez
http://www.michael--martinez.com
7 years, 5 months
Re: (ITS#8411) segfault on slapd 2.4.44
by hyc＠symas.com
This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2
password module in your installation. Closing this ITS.
Michael Martinez wrote:
> OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux
>
> (gdb) info shared
>>From To Syms Read Shared Object Library
> 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
> 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7
> 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2
> 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so
> 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2
> 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0
> 0xb6c35e80 0xb6d071c0 Yes (*)
> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1
> 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2
> 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0
> 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6
> 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3
> 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1
> 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1
> 0xb6f25268 0xb6f298e0 Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so
> 0xb69ced8c 0xb69d0ae0 Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so
> 0xb69c107c 0xb69c3bbc Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so
> 0xb69ad400 0xb69b59e4 Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so
> 0xb699fe04 0xb69a2004 Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so
> 0xb6993d5c 0xb69957f0 Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so
> 0xb6987d50 0xb6989974 Yes (*)
> /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so
> 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so
> (*): Shared library is missing debugging information.
>
> (gdb) bt
> #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
> #1 0xb6c3f344 in SHA256_Update ()
> from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20,
> cred=0x1a53468,
> text=0xa11cab98) at slapd-sha2.c:256
> #3 0x00121f58 in lutil_passwd ()
> #4 0x0006ec98 in slap_passwd_check ()
> #5 0x000e4db8 in bdb_bind ()
> #6 0x0005bbdc in fe_op_bind ()
> #7 0x0005b568 in do_bind ()
> #8 0x000403b8 in ?? ()
> Cannot access memory at address 0x0
> #9 0x000403b8 in ?? ()
> Cannot access memory at address 0x0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote:
>> mwtzzz(a)gmail.com wrote:
>>>
>>> Full_Name: Michael Martinez
>>> Version: 2.4.44
>>> OS: ubuntu wheezy
>>
>>
>> There is no such OS.
>>
>>> URL:
>>> Submission from: (NULL) (99.113.34.53)
>>>
>>>
>>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults
>>> anytime I
>>> run 'passwd', attempt to ssh into the box, etc.
>>>
>>> this is on raspberry pi (debian wheezy).
>>>
>>> Previously running the latest package 2.4.31. Then installed
>>> openldap-2.4.44
>>> from source, did slapcat from the old version and slapadd to import it to
>>> the
>>> new version. Loads fine and can run simple commands like "id" for ldap
>>> users.
>>> But get core dump with password changes, ssh from other boxes, etc.
>>> A%A[Thread debugging using libthread_db enabled]
>>> Using host libthread_db library
>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>> Core was generated by `/usr/local/openldap/libexec/slapd -f
>>> /etc/ldap/slapd.conf
>>> -F /ec/ldap/slapd.d'.
>>> Program terminated with signal 11, Segmentation fault.
>>> #0 0xb6f350a0 in memcpy () from
>>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
>>> (gdb)
>>
>>
>> Please provide the full stack trace.
>>
>> Also output from "info shared".
>>
>> --
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com
OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux
(gdb) info shared
>From To Syms Read Shared Object Library
0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7
0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2
0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so
0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2
0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0
0xb6c35e80 0xb6d071c0 Yes (*)
/usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1
0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2
0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0
0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6
0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3
0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1
0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1
0xb6f25268 0xb6f298e0 Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so
0xb69ced8c 0xb69d0ae0 Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/libplain.so
0xb69c107c 0xb69c3bbc Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so
0xb69ad400 0xb69b59e4 Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so
0xb699fe04 0xb69a2004 Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so
0xb6993d5c 0xb69957f0 Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so
0xb6987d50 0xb6989974 Yes (*)
/usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so
0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so
(*): Shared library is missing debugging information.
(gdb) bt
#0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
#1 0xb6c3f344 in SHA256_Update ()
from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20,
cred=0x1a53468,
text=0xa11cab98) at slapd-sha2.c:256
#3 0x00121f58 in lutil_passwd ()
#4 0x0006ec98 in slap_passwd_check ()
#5 0x000e4db8 in bdb_bind ()
#6 0x0005bbdc in fe_op_bind ()
#7 0x0005b568 in do_bind ()
#8 0x000403b8 in ?? ()
Cannot access memory at address 0x0
#9 0x000403b8 in ?? ()
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote:
> mwtzzz(a)gmail.com wrote:
>>
>> Full_Name: Michael Martinez
>> Version: 2.4.44
>> OS: ubuntu wheezy
>
>
> There is no such OS.
>
>> URL:
>> Submission from: (NULL) (99.113.34.53)
>>
>>
>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults
>> anytime I
>> run 'passwd', attempt to ssh into the box, etc.
>>
>> this is on raspberry pi (debian wheezy).
>>
>> Previously running the latest package 2.4.31. Then installed
>> openldap-2.4.44
>> from source, did slapcat from the old version and slapadd to import it to
>> the
>> new version. Loads fine and can run simple commands like "id" for ldap
>> users.
>> But get core dump with password changes, ssh from other boxes, etc.
>> A%A[Thread debugging using libthread_db enabled]
>> Using host libthread_db library
>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>> Core was generated by `/usr/local/openldap/libexec/slapd -f
>> /etc/ldap/slapd.conf
>> -F /ec/ldap/slapd.d'.
>> Program terminated with signal 11, Segmentation fault.
>> #0 0xb6f350a0 in memcpy () from
>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
>> (gdb)
>
>
> Please provide the full stack trace.
>
> Also output from "info shared".
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
---
Michael Martinez
http://www.michael--martinez.com
7 years, 5 months
