Full_Name: Christian B.sch Version: 2.4.42 OS: FreeBSD 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:628:2130:4458::93) I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: olcOverlay={0}syncprov.ldif olcOverlay={1}dds.ldif olcOverlay={2}accesslog.ldif olcOverlay={3}unique.ldif olcOverlay={4}ppolicy.ldif olcOverlay={5}refint.ldif olcOvery%y={6}memberof.ldif olcOverlay={7}dynlist.ldif started, everything is fine. Then I added an empty base tree: dn: dc=example,dc=net objectClass: dcObject objectClass: organization o: ORG dc: example dn: cn=admin,dc=example,dc=net objectClass: organizationalRole cn: LDAP Admin cn: admin dn: o=org,dc=example,dc=net o: ORG objectClass: organization objectClass: top After that, if slapd is restarted: /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd If the db files are removed again, the startup works again, and if the dds overlay is removed the startup is always working even if the database isn't empty.
Hello Christian, On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch@fhv.at wrote: >I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: >olcOverlay={0}syncprov.ldif >olcOverlay={1}dds.ldif >olcOverlay={2}accesslog.ldif >olcOverlay={3}unique.ldif >olcOverlay={4}ppolicy.ldif >olcOverlay={5}refint.ldif >olcOverlay={6}memberof.ldif >olcOverlay={7}dynlist.ldif >started, everything is fine. > >Then I added an empty base tree: >dn: dc=example,dc=net >objectClass: dcObject >objectClass: organization >o: ORG >dc: example > >dn: cn=admin,dc=example,dc=net >objectClass: organizationalRole >cn: LDAP Admin >cn: admin > >dn: o=org,dc=example,dc=net >o: ORG >objectClass: organization >objectClass: top I tried to reproduce your problem under openldap 2.4.42 on Linux (Debian), using the attached config and the data LDIF you provided, but didn't observe any problems. Would you please provide more details about the configuration that causes the problem, including the options specified when you built OpenLDAP, and any applicable log messages? It would also be good to know if you can reproduce the problem using current sources from git branch OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate. thanks, Ryan dn: cn=config objectClass: olcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:servers/slapd/schema/core.ldif include: file:servers/slapd/schema/cosine.ldif include: file:servers/slapd/schema/inetorgperson.ldif include: file:servers/slapd/schema/nis.ldif include: file:servers/slapd/schema/dyngroup.ldif include: file:servers/slapd/schema/ppolicy.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcSuffix: dc=example,dc=net olcDbDirectory: data.d olcRootDN: cn=root,dc=example,dc=net olcRootPW: secret dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcSuffix: cn=accesslog olcDbDirectory: accesslog.d dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig dn: olcOverlay={1}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig dn: olcOverlay={2}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig olcAccessLogDB: cn=accesslog dn: olcOverlay={3}unique,olcDatabase={1}mdb,cn=config objectClass: olcUniqueConfig dn: olcOverlay={4}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcPPolicyConfig dn: olcOverlay={5}refint,olcDatabase={1}mdb,cn=config objectClass: olcRefintConfig dn: olcOverlay={6}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf dn: olcOverlay={7}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcDynamicList
> On 13 Nov 2015, at 06:30 , Ryan Tandy <ryan@openldap.org> wrote: > > Hello Christian, > > On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch@fhv.at wrote: >> I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: >> olcOverlay={0}syncprov.ldif >> olcOverlay={1}dds.ldif >> olcOverlay={2}accesslog.ldif >> olcOverlay={3}unique.ldif >> olcOverlay={4}ppolicy.ldif >> olcOverlay={5}refint.ldif >> olcOverlay={6}memberof.ldif >> olcOverlay={7}dynlist.ldif >> started, everything is fine. >> >> Then I added an empty base tree: >> dn: dc=example,dc=net >> objectClass: dcObject >> objectClass: organization >> o: ORG >> dc: example >> >> dn: cn=admin,dc=example,dc=net >> objectClass: organizationalRole >> cn: LDAP Admin >> cn: admin >> >> dn: o=org,dc=example,dc=net >> o: ORG >> objectClass: organization >> objectClass: top > > I tried to reproduce your problem under openldap 2.4.42 on Linux (Debian), using the attached config and the data LDIF you provided, but didn't observe any problems. Would you please provide more details about the configuration that causes the problem, including the options specified when you built OpenLDAP, and any applicable log messages? It would also be good to know if you can reproduce the problem using current sources from git branch OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate. The last lines of debug.log are: Nov 16 08:39:36 openldap1 slapd[49483]: slapd startup: initiated. Nov 16 08:39:36 openldap1 slapd[49483]: backend_startup_one: starting "cn=config" Nov 16 08:39:36 openldap1 slapd[49483]: config_back_db_open Nov 16 08:39:36 openldap1 slapd[49483]: backend_startup_one: starting "dc=example,dc=net" Nov 16 08:39:36 openldap1 slapd[49483]: mdb_db_open: database "dc=example,dc=net": dbenv_open(/var/db/openldap-data). Nov 16 08:39:36 openldap1 slapd[49483]: => mdb_search Nov 16 08:39:36 openldap1 slapd[49483]: mdb_dn2entry("dc=example,dc=net") Nov 16 08:39:36 openldap1 slapd[49483]: => mdb_dn2id("dc=example,dc=net") Nov 16 08:39:36 openldap1 slapd[49483]: <= mdb_dn2id: got id=0x1 Nov 16 08:39:36 openldap1 slapd[49483]: => mdb_entry_decode: Nov 16 08:39:36 openldap1 slapd[49483]: <= mdb_entry_decode Nov 16 08:39:36 openldap1 slapd[49483]: search_candidates: base="dc=example,dc=net" (0x00000001) scope=2 Nov 16 08:39:36 openldap1 slapd[49483]: => mdb_equality_candidates (objectClass) Nov 16 08:39:36 openldap1 slapd[49483]: => key_read Nov 16 08:39:36 openldap1 slapd[49483]: <= mdb_index_read: failed (-30798) Nov 16 08:39:36 openldap1 slapd[49483]: <= mdb_equality_candidates: id=0, first=0, last=0 Nov 16 08:39:36 openldap1 slapd[49483]: => mdb_equality_candidates (objectClass) Nov 16 08:39:36 openldap1 slapd[49483]: => key_read Nov 16 08:39:36 openldap1 slapd[49483]: <= mdb_index_read: failed (-30798) Nov 16 08:39:36 openldap1 slapd[49483]: <= mdb_equality_candidates: id=0, first=0, last=0 Nov 16 08:39:36 openldap1 slapd[49483]: mdb_search_candidates: id=0 first=0 last=0 Nov 16 08:39:36 openldap1 slapd[49483]: mdb_search: no candidates Nov 16 08:39:36 openldap1 slapd[49483]: send_ldap_result: conn=-1 op=0 p=0 Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_required entry (reqStart=20151116073936.000002Z,cn=log), objectClass "auditSearch" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "objectClass" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "structuralObjectClass" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqStart" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqEnd" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqType" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqSession" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqAuthzID" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqDN" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqResult" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqScope" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqDerefAliases" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqAttrsOnly" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqFilter" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqAttr" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqEntries" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqTimeLimit" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqSizeLimit" The build config is: # This file is auto-generated by 'make config'. # Options for openldap-server-2.4.42_2 _OPTIONS_READ=openldap-server-2.4.42_2 _FILE_COMPLETE_OPTIONS_LIST=ACCESSLOG ACI AUDITLOG BDB COLLECT CONSTRAINT DDS DEBUG DEREF DNSSRV DYNACL DYNAMIC_BACKENDS DYNGROUP DYNLIST FETCH GSSAPI LMPASSWD MDB MEMBEROF ODBC OUTLOOK PASSWD PERL PPOLICY PROXYCACHE REFINT RELAY RETCODE RLOOKUPS RWM SASL SEQMOD SHA2 SHELL SLAPI SMBPWD SOCK SSSVLV SYNCPROV TCP_WRAPPERS TRANSLUCENT UNIQUE VALSORT OPTIONS_FILE_SET+=ACCESSLOG OPTIONS_FILE_UNSET+=ACI OPTIONS_FILE_SET+=AUDITLOG OPTIONS_FILE_UNSET+=BDB OPTIONS_FILE_SET+=COLLECT OPTIONS_FILE_SET+=CONSTRAINT OPTIONS_FILE_SET+=DDS OPTIONS_FILE_SET+=DEBUG OPTIONS_FILE_SET+=DEREF OPTIONS_FILE_SET+=DNSSRV OPTIONS_FILE_UNSET+=DYNACL OPTIONS_FILE_SET+=DYNAMIC_BACKENDS OPTIONS_FILE_SET+=DYNGROUP OPTIONS_FILE_SET+=DYNLIST OPTIONS_FILE_SET+=FETCH OPTIONS_FILE_UNSET+=GSSAPI OPTIONS_FILE_UNSET+=LMPASSWD OPTIONS_FILE_SET+=MDB OPTIONS_FILE_SET+=MEMBEROF OPTIONS_FILE_UNSET+=ODBC OPTIONS_FILE_SET+=OUTLOOK OPTIONS_FILE_SET+=PASSWD OPTIONS_FILE_SET+=PERL OPTIONS_FILE_SET+=PPOLICY OPTIONS_FILE_SET+=PROXYCACHE OPTIONS_FILE_SET+=REFINT OPTIONS_FILE_SET+=RELAY OPTIONS_FILE_SET+=RETCODE OPTIONS_FILE_SET+=RLOOKUPS OPTIONS_FILE_SET+=RWM OPTIONS_FILE_SET+=SASL OPTIONS_FILE_SET+=SEQMOD OPTIONS_FILE_SET+=SHA2 OPTIONS_FILE_UNSET+=SHELL OPTIONS_FILE_UNSET+=SLAPI OPTIONS_FILE_SET+=SMBPWD OPTIONS_FILE_SET+=SOCK OPTIONS_FILE_SET+=SSSVLV OPTIONS_FILE_SET+=SYNCPROV OPTIONS_FILE_SET+=TCP_WRAPPERS OPTIONS_FILE_SET+=TRANSLUCENT OPTIONS_FILE_SET+=UNIQUE OPTIONS_FILE_SET+=VALSORT I’ll try the build with your mentioned branch soon and get in touch again. thanks, Chris > > thanks, > Ryan > > dn: cn=config > objectClass: olcGlobal > > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > > include: file:servers/slapd/schema/core.ldif > > include: file:servers/slapd/schema/cosine.ldif > > include: file:servers/slapd/schema/inetorgperson.ldif > > include: file:servers/slapd/schema/nis.ldif > > include: file:servers/slapd/schema/dyngroup.ldif > > include: file:servers/slapd/schema/ppolicy.ldif > > dn: olcDatabase={1}mdb,cn=config > objectClass: olcMdbConfig > olcSuffix: dc=example,dc=net > olcDbDirectory: data.d > olcRootDN: cn=root,dc=example,dc=net > olcRootPW: secret > > dn: olcDatabase={2}mdb,cn=config > objectClass: olcMdbConfig > olcSuffix: cn=accesslog > olcDbDirectory: accesslog.d > > dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config > objectClass: olcSyncProvConfig > > dn: olcOverlay={1}dds,olcDatabase={1}mdb,cn=config > objectClass: olcDDSConfig > > dn: olcOverlay={2}accesslog,olcDatabase={1}mdb,cn=config > objectClass: olcAccessLogConfig > olcAccessLogDB: cn=accesslog > > dn: olcOverlay={3}unique,olcDatabase={1}mdb,cn=config > objectClass: olcUniqueConfig > > dn: olcOverlay={4}ppolicy,olcDatabase={1}mdb,cn=config > objectClass: olcPPolicyConfig > > dn: olcOverlay={5}refint,olcDatabase={1}mdb,cn=config > objectClass: olcRefintConfig > > dn: olcOverlay={6}memberof,olcDatabase={1}mdb,cn=config > objectClass: olcMemberOf > > dn: olcOverlay={7}dynlist,olcDatabase={1}mdb,cn=config > objectClass: olcDynamicList
> On 13 Nov 2015, at 06:30 , Ryan Tandy <ryan@openldap.org> wrote: > > Hello Christian, > > On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch@fhv.at wrote: >> I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: >> olcOverlay={0}syncprov.ldif >> olcOverlay={1}dds.ldif >> olcOverlay={2}accesslog.ldif >> olcOverlay={3}unique.ldif >> olcOverlay={4}ppolicy.ldif >> olcOverlay={5}refint.ldif >> olcOverlay={6}memberof.ldif >> olcOverlay={7}dynlist.ldif >> started, everything is fine. >> >> Then I added an empty base tree: >> dn: dc=example,dc=net >> objectClass: dcObject >> objectClass: organization >> o: ORG >> dc: example >> >> dn: cn=admin,dc=example,dc=net >> objectClass: organizationalRole >> cn: LDAP Admin >> cn: admin >> >> dn: o=org,dc=example,dc=net >> o: ORG >> objectClass: organization >> objectClass: top > > I tried to reproduce your problem under openldap 2.4.42 on Linux (Debian), using the attached config and the data LDIF you provided, but didn't observe any problems. Would you please provide more details about the configuration that causes the problem, including the options specified when you built OpenLDAP, and any applicable log messages? It would also be good to know if you can reproduce the problem using current sources from git branch OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate. on freebsd 10.2 build from source failed with the message: cd back-mdb; make all /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c -o mdb.o ./../../../libraries/liblmdb/mdb.c:4758:39: error: use of undeclared identifier 'O_DSYNC' env->me_mfd = open(dpath, oflags | MDB_DSYNC, mode); ^ ./../../../libraries/liblmdb/mdb.c:409:20: note: expanded from macro 'MDB_DSYNC' # define MDB_DSYNC O_DSYNC ^ ./../../../libraries/liblmdb/mdb.c:9681:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ^ 1 warning and 1 error generated. *** Error code 1 Stop. make[3]: stopped in /root/openldap/servers/slapd/back-mdb *** Error code 1 regards, chris > > thanks, > Ryan > > dn: cn=config > objectClass: olcGlobal > > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > > include: file:servers/slapd/schema/core.ldif > > include: file:servers/slapd/schema/cosine.ldif > > include: file:servers/slapd/schema/inetorgperson.ldif > > include: file:servers/slapd/schema/nis.ldif > > include: file:servers/slapd/schema/dyngroup.ldif > > include: file:servers/slapd/schema/ppolicy.ldif > > dn: olcDatabase={1}mdb,cn=config > objectClass: olcMdbConfig > olcSuffix: dc=example,dc=net > olcDbDirectory: data.d > olcRootDN: cn=root,dc=example,dc=net > olcRootPW: secret > > dn: olcDatabase={2}mdb,cn=config > objectClass: olcMdbConfig > olcSuffix: cn=accesslog > olcDbDirectory: accesslog.d > > dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config > objectClass: olcSyncProvConfig > > dn: olcOverlay={1}dds,olcDatabase={1}mdb,cn=config > objectClass: olcDDSConfig > > dn: olcOverlay={2}accesslog,olcDatabase={1}mdb,cn=config > objectClass: olcAccessLogConfig > olcAccessLogDB: cn=accesslog > > dn: olcOverlay={3}unique,olcDatabase={1}mdb,cn=config > objectClass: olcUniqueConfig > > dn: olcOverlay={4}ppolicy,olcDatabase={1}mdb,cn=config > objectClass: olcPPolicyConfig > > dn: olcOverlay={5}refint,olcDatabase={1}mdb,cn=config > objectClass: olcRefintConfig > > dn: olcOverlay={6}memberof,olcDatabase={1}mdb,cn=config > objectClass: olcMemberOf > > dn: olcOverlay={7}dynlist,olcDatabase={1}mdb,cn=config > objectClass: olcDynamicList
Hello Christian, On Mon, Nov 16, 2015 at 07:46:31AM +0000, BÖSCH Christian wrote: >The last lines of debug.log are: > >[…] > >The build config is: >[…] Thanks for that information, however I still need more details about your actual running config in order to reproduce the problem. Could you please provide the output of slapcat -b 'cn=config' (plus an appropriate -F setting) either from a test setup that shows the problem, or from your actual config with passwords/sensitive information removed (note some are emitted in base64 form). On Mon, Nov 16, 2015 at 02:06:17PM +0000, BÖSCH Christian wrote: >on freebsd 10.2 build from source failed with the message: > > cd back-mdb; make all >/bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c > cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c -o mdb.o >./../../../libraries/liblmdb/mdb.c:4758:39: error: use of undeclared identifier 'O_DSYNC' > env->me_mfd = open(dpath, oflags | MDB_DSYNC, mode); > ^ >./../../../libraries/liblmdb/mdb.c:409:20: note: expanded from macro 'MDB_DSYNC' ># define MDB_DSYNC O_DSYNC > ^ >./../../../libraries/liblmdb/mdb.c:9681:46: warning: data argument not used by format string [-Wformat-extra-args] > (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); > ^ >1 warning and 1 error generated. >*** Error code 1 > >Stop. >make[3]: stopped in /root/openldap/servers/slapd/back-mdb >*** Error code 1 This is ITS#7209 <http://www.openldap.org/its/?findid=7209>. The patch linked at the top of that should allow it to build. thanks, Ryan
On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >The slapcat output is attached below. Thanks for that. Now I did reproduce the bug, in current git master and also in RE24. The backtrace (line numbers from master) is: Program received signal SIGSEGV, Segmentation fault. 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 2760 flags |= env->me_flags & MDB_WRITEMAP; (gdb) bt #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 At first glance it looks like another problem related to ITS#8133, where dds triggers calls into another module (this time, accesslog) before it has actually initialized.
ryan@openldap.org wrote: > On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >> The slapcat output is attached below. > > Thanks for that. Now I did reproduce the bug, in current git master and > also in RE24. This particular problem can be fixed by setting op->o_do_not_cache in dds_count. Not sure what's needed for a more general solution. > The backtrace (line numbers from master) is: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > 2760 flags |= env->me_flags & MDB_WRITEMAP; > (gdb) bt > #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 > #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 > #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 > #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 > #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 > #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 > #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 > #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 > #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 > #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 > #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 > #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 > #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 > #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 > #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 > #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 > #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 > #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 > > At first glance it looks like another problem related to ITS#8133, where > dds triggers calls into another module (this time, accesslog) before it > has actually initialized. > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Will there be a patch or will this be fixed in the next version? > On 17 Nov 2015, at 16:56 , Ryan Tandy <ryan@openldap.org> wrote: > > On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >> The slapcat output is attached below. > > Thanks for that. Now I did reproduce the bug, in current git master and also in RE24. > > The backtrace (line numbers from master) is: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > 2760 flags |= env->me_flags & MDB_WRITEMAP; > (gdb) bt > #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 > #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 > #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 > #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 > #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 > #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 > #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 > #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 > #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 > #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 > #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 > #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 > #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 > #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 > #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 > #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 > #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 > #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 > > At first glance it looks like another problem related to ITS#8133, where dds triggers calls into another module (this time, accesslog) before it has actually initialized.
moved from Incoming to Software Bugs
Fixed in master
trunk: commit eefe12366c5c6de25a9a7067000b443d76043725 Author: Howard Chu <hyc@openldap.org> Date: Wed Jan 13 16:35:43 2021 +0000 ITS#8307 fix slapo-accesslog: noop if logDB isn't open yet Add be_flag for DB OPEN status commit 85b68aa5e221397081249fe5efe7330a6d738ecf Author: Howard Chu <hyc@openldap.org> Date: Wed Jan 13 16:39:24 2021 +0000 ITS#8307 slapo-dds: mark internal searches as do_not_cache commit 9d440e3d2829258b803a2e663343c05341945446 Author: Howard Chu <hyc@openldap.org> Date: Wed Jan 13 16:58:42 2021 +0000 ITS#8307 slapo-accesslog additional check
RE25: commit eefe12366c5c6de25a9a7067000b443d76043725 Author: Howard Chu <hyc@openldap.org> Date: Wed Jan 13 16:35:43 2021 +0000 ITS#8307 fix slapo-accesslog: noop if logDB isn't open yet Add be_flag for DB OPEN status commit 85b68aa5e221397081249fe5efe7330a6d738ecf Author: Howard Chu <hyc@openldap.org> Date: Wed Jan 13 16:39:24 2021 +0000 ITS#8307 slapo-dds: mark internal searches as do_not_cache commit 9d440e3d2829258b803a2e663343c05341945446 Author: Howard Chu <hyc@openldap.org> Date: Wed Jan 13 16:58:42 2021 +0000 ITS#8307 slapo-accesslog additional check