What git revision of LMDB did you test?
The last tag from git repository, 0.9.16
Thanks.
Subject: Re: RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17) To: sfhacker@hotmail.com From: hyc@symas.com Date: Wed, 25 Nov 2015 13:02:44 +0000
Sergio NNX wrote:
Ciao,
We are testing the latest version of Cyrus SASL against LMDB (on Windows, built from source) and when we run the testsuite app, we get a runtime exception shown below:
Please use the -technical mailing list for LMDB discussions.
... ... Testing sasl_listmech()... ok Testing serverstart... All memory accounted for! ok Testing client-first/no-server-last correctly... SRP --> start
Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00432a4d in mdb_node_search (mc=mc@entry=0x289608, key=key@entry=0x289850, exactp=exactp@entry=0x289604) at mdb.c:4943 #2 0x004361bc in mdb_cursor_set (mc=mc@entry=0x289608, key=key@entry=0x289850, data=data@entry=0x289858, op=op@entry=MDB_SET, exactp=exactp@entry=0x289604) at mdb.c:5725 #3 0x0043667c in mdb_get (txn=0x35c7b0, dbi=1, key=0x289850, data=0x289858) at mdb.c:5391 #4 0x00431a55 in _sasldb_getdata () #5 0x0042fda3 in sasldb_auxprop_lookup () #6 0x004119f7 in _sasl_auxprop_lookup () #7 0x00413a6c in _sasl_canon_user_lookup () #8 0x0042ea7e in srp_server_mech_step () #9 0x0040cddd in sasl_server_step () #10 0x0040d361 in sasl_server_start () #11 0x0040458f in doauth () #12 0x004060d6 in test_clientfirst () #13 0x00406405 in foreach_mechanism () #14 0x00733d1f in main () (gdb)
Building SASL against Berkeley DB does not show the same issue.
Any pointers will be greatly appreciated.
Thanks.
Sergio.
Sergio NNX wrote:
What git revision of LMDB did you test?
The last tag from git repository, 0.9.16
Thanks.
Subject: Re: RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17) To: sfhacker@hotmail.com From: hyc@symas.com Date: Wed, 25 Nov 2015 13:02:44 +0000
Sergio NNX wrote:
Ciao,
We are testing the latest version of Cyrus SASL against LMDB (on Windows, built from source) and when we run the testsuite app, we get a runtime exception shown below:
Please use the -technical mailing list for LMDB discussions.
Using Cyrus-SASL 2.1.26 and LMDB 0.9.17 on Linux, I don't see any such problem - it fails at GSSAPI because I have no kerberos creds.
violino:~/BLD/sold/build/sasl.64/utils> ./testsuite NOTE: -For KERBEROS_V4 must be able to read srvtab file (usually /etc/srvtab) -For GSSAPI must be able to read srvtab (/etc/krb5.keytab) -For both KERBEROS_V4 and GSSAPI you must have non-expired tickets -For OTP (w/OPIE) must be able to read/write opiekeys (/etc/opiekeys) -For OTP you must have a non-expired secret -Must be able to read sasldb, which needs to be setup with a username and a password (see top of testsuite.c)
All memory accounted for! Checking plaintext passwords... ok All memory accounted for! Random number functions... ok All memory accounted for! Testing base64 functions... ok All memory accounted for! Testing auxprop functions... ok All memory accounted for! All memory accounted for! All memory accounted for! All memory accounted for! All memory accounted for! All memory accounted for! Tests of sasl_{server|client}_init()... ok Testing sasl_listmech()... [PLAIN,EXTERNAL,DIGEST-MD5,GSS-SPNEGO,GSSAPI,SCRAM-SHA-1,SRP] Client mechlist: [SRP,SCRAM-SHA-1,GSSAPI,GSS-SPNEGO,DIGEST-MD5,EXTERNAL,PLAIN] We have the following mechs: [SRP,SCRAM-SHA-1,GSSAPI,GSS-SPNEGO,DIGEST-MD5,EXTERNAL,PLAIN] All memory accounted for! Testing sasl_listmech()... ok All memory accounted for! Testing serverstart...ok Testing client-first/no-server-last correctly... SRP --> start SRP --> successful result SCRAM-SHA-1 --> start SCRAM-SHA-1 --> successful result GSSAPI --> start Failed with: sasl_client_start() error
... ... Testing sasl_listmech()... ok Testing serverstart... All memory accounted for! ok Testing client-first/no-server-last correctly... SRP --> start
Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00432a4d in mdb_node_search (mc=mc@entry=0x289608, key=key@entry=0x289850, exactp=exactp@entry=0x289604) at mdb.c:4943 #2 0x004361bc in mdb_cursor_set (mc=mc@entry=0x289608, key=key@entry=0x289850, data=data@entry=0x289858, op=op@entry=MDB_SET, exactp=exactp@entry=0x289604) at mdb.c:5725 #3 0x0043667c in mdb_get (txn=0x35c7b0, dbi=1, key=0x289850, data=0x289858) at mdb.c:5391 #4 0x00431a55 in _sasldb_getdata () #5 0x0042fda3 in sasldb_auxprop_lookup () #6 0x004119f7 in _sasl_auxprop_lookup () #7 0x00413a6c in _sasl_canon_user_lookup () #8 0x0042ea7e in srp_server_mech_step () #9 0x0040cddd in sasl_server_step () #10 0x0040d361 in sasl_server_start () #11 0x0040458f in doauth () #12 0x004060d6 in test_clientfirst () #13 0x00406405 in foreach_mechanism () #14 0x00733d1f in main () (gdb)
Building SASL against Berkeley DB does not show the same issue.
Any pointers will be greatly appreciated.
Thanks.
Sergio.
Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00432a4d in mdb_node_search (mc=mc@entry=0x289608, key=key@entry=0x289850, exactp=exactp@entry=0x289604) at mdb.c:4943 #2 0x004361bc in mdb_cursor_set (mc=mc@entry=0x289608, key=key@entry=0x289850, data=data@entry=0x289858, op=op@entry=MDB_SET, exactp=exactp@entry=0x289604) at mdb.c:5725 #3 0x0043667c in mdb_get (txn=0x35c7b0, dbi=1, key=0x289850, data=0x289858) at mdb.c:5391 #4 0x00431a55 in _sasldb_getdata () #5 0x0042fda3 in sasldb_auxprop_lookup () #6 0x004119f7 in _sasl_auxprop_lookup () #7 0x00413a6c in _sasl_canon_user_lookup () #8 0x0042ea7e in srp_server_mech_step () #9 0x0040cddd in sasl_server_step () #10 0x0040d361 in sasl_server_start () #11 0x0040458f in doauth () #12 0x004060d6 in test_clientfirst () #13 0x00406405 in foreach_mechanism () #14 0x00733d1f in main () (gdb)
Using Cyrus-SASL 2.1.26 and LMDB 0.9.17 on Linux, I don't see any such problem
- it fails at GSSAPI because I have no kerberos creds.
Linux you say? You are a lucky man indeed! On Windows, it segfaults right after the first mechanism.
I'm far from an expert, but the issue seems to be related to the 'KEEP_DB_OPEN' define and/or feature. I lack the knowledge as to know/understand why!
Thanks anyway for your time on this.
Sergio.
openldap-technical@openldap.org