openldap-bugs December 2020

openldap-bugs@openldap.org

3 participants
89 discussions

[Issue 9380] New: connection_write_resume should be type void rather than int
by openldap-its＠openldap.org 08 Feb '21

08 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9380 Issue ID: 9380 Summary: connection_write_resume should be type void rather than int Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- connection_write_resume does not return anything, but is declared to return an int. This can cause compile failure depending on the flags used during compilation (-Werror=return-type) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9322] New: Update admin guide to recommend OpenSSL 1.1 as a minimum release
by openldap-its＠openldap.org 08 Feb '21

08 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9322 Issue ID: 9322 Summary: Update admin guide to recommend OpenSSL 1.1 as a minimum release Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.5, we need to update the recommended OpenSSL version to be 1.1 or later. appendix-recommended-versions.sdf -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9388] New: mdb_stat for DupSort DBI shows incorrect data
by openldap-its＠openldap.org 04 Feb '21

04 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9388 Issue ID: 9388 Summary: mdb_stat for DupSort DBI shows incorrect data Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: AskAlexSharov(a)gmail.com Target Milestone: --- It doesn't include pages pages used for values. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Bug 9205] New: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap
by openldap-its＠openldap.org 01 Feb '21

01 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9205 Bug ID: 9205 Summary: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Created attachment 700 --> https://bugs.openldap.org/attachment.cgi?id=700&action=edit test script copied from test022-ppolicy and modified to show the trouble Hello, I'm doing a OpenLDAP test with a master/slave replication configuration including ppolicy overlay. I would like to enable password change from the slave replica with chain overlay, in order to validate the ppolicy olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to master with SASL External authentication with client certificate. The client certificate correspond to a user DN entry with "manage" rights on the master server (the same used for the replication). This user DN has authzTo attribute in order to match the correct PROXYAUTHZ request from its dn to user DN. All of this configuration works on replica when i do first a failed authentication (err=49) on replica. The pwdFailureTime value is updated on the DN entry from replica to slave normally. I'm also able to do after some self entry update on some attribute such as password or others from replica to master. But the weird behavior is that i need to run first an failed authentication, otherwise if i try to change attribute on the slave server, it respond an err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The only way to retrieve correct behavior is to restart slapd, and redo one failed authentication first. It seems that the chain overlay do not connect the master server at startup. I've done a modification of test script test022-ppolicy to test022-policy-chain which use the same LDIF source and show the problem of modification on the consumer not "relayed" to the supplier if a fail operation is not done before. Regards -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Issue 9340] New: Setting slapd.conf listener-threads > 1 causes Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s)
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9340 Issue ID: 9340 Summary: Setting slapd.conf listener-threads > 1 causes Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s) Product: OpenLDAP Version: 2.4.52 Hardware: Other OS: Solaris Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- Created attachment 761 --> https://bugs.openldap.org/attachment.cgi?id=761&action=edit Output from -d 5 option This is not a new issue, the same is observed on version 2.4.45 through 2.4.53 Setting listener-threads via slapd.conf file on Sun4v (SPARC T4-1) system to a value other than 1 results in "Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s), file daemon.c" when starting slapd. The same does not occur when using Directory (-F) configuration. # grep '^listener-threads' /etc/openldap/slapd.conf listener-threads 8 # /usr/lib/slapd -u openldap -g openldap \ > -f /etc/openldap/slapd.conf \ > -h 'ldap:/// ldapi:/// ldaps:///' -d 5 > slapd.error 2>&1 Abort (core dumped) # tail slapd.error 5f578024 >>> dnNormalize: <cn=Current> 5f578024 <<< dnNormalize: <cn=current> 5f578024 >>> dnNormalize: <cn=Uptime> 5f578024 <<< dnNormalize: <cn=uptime> 5f578024 >>> dnNormalize: <cn=Read> 5f578024 <<< dnNormalize: <cn=read> 5f578024 >>> dnNormalize: <cn=Write> 5f578024 <<< dnNormalize: <cn=write> 5f578024 slapd starting Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s), file daemon.c, line 903 # /usr/lib/slapd -VVV @(#) $OpenLDAP: slapd 2.4.53 (Sep 8 2020 03:15:21) $ openldap Included static overlays: accesslog auditlog collect constraint dds deref dyngroup dynlist memberof ppolicy pcache refint retcode rwm seqmod sssvlv syncprov translucent unique valsort Included static backends: config ldif monitor ldap mdb meta null passwd relay shell # When running under debugger the issue is not observed. The core file reveals the following threads: # /opt/solarisstudio12.4/bin/dbx /usr/lib/slapd core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 8.0' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libc.so.1 Reading libldap_r-2.4.so.2.11.1 Reading liblber-2.4.so.2.11.1 Reading libsasl2.so.3.0.0 Reading liblogin.so.3.0.0 Reading libgssapiv2.so.3.0.0 Reading libgssapi_krb5.so.2.2 Reading libkrb5.so.3.3 Reading libcom_err.so.3.0 Reading libkrb5support.so.0.1 Reading libk5crypto.so.3.1 Reading libucrypto.so.1 Reading libbsm.so.1 Reading libtsol.so.2 Reading libinetutil.so.1 Reading libcryptoutil.so.1 Reading libelf.so.1 Reading libz.so.1 Reading libresolv.so.2 Reading libkwarn.so.1 Reading libplain.so.3.0.0 Reading libotp.so.3.0.0 Reading libcrypto.so.1.0.0 Reading libsasldb.so.3.0.0 Reading libdb-5.3.so Reading libscram.so.3.0.0 Reading libltdl.so.7.3.1 Reading libssl.so.1.0.0 Reading libuuid.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0x0007fdd05cce17a8: __lwp_sigqueue+0x0008: bcc,a,pt %icc,__lwp_sigqueue+0x18 ! 0x7fdd05cce17b8 (dbx) lwps l@1 LWP suspended in uucopy() o>l@2 signal SIGABRT in __lwp_sigqueue() l@3 LWP suspended in __pollsys() l@4 LWP suspended in __pollsys() l@5 LWP suspended in __pollsys() (dbx) where current thread: t@2 =>[1] __lwp_sigqueue(0x0, 0xa00386a7d98, 0x6, 0x0, 0xffffffffffffffff, 0x0), at 0x7fdd05cce17a8 [2] raise(0x6, 0x7fdd0583ff060, 0x5, 0x5, 0x0, 0x0), at 0x7fdd05cc2af0c [3] abort(0x1, 0x1210, 0x0, 0x1000, 0x7fdd05ce3c278, 0x1a278), at 0x7fdd05cbfa144 [4] _assert(0x10005d7a8, 0x10005d7c8, 0x387, 0x9, 0x8200, 0x7fdd05ce22000), at 0x7fdd05cbfb158 [5] slapd_daemon_task(0xc4, 0xffffffffffcdb7c8, 0x100382000, 0x324800, 0x61bf4f2270, 0x100406d3c), at 0x1000c118c (dbx) lwp l@1 t@1 (l@1) stopped in uucopy at 0x7fdd05cce1d34 0x0007fdd05cce1d34: uucopy+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] uucopy(0x0, 0x7fdd0553fff10, 0xb0, 0xfffffffffffffff8, 0x0, 0xfffffe59ec25a990), at 0x7fdd05cce1d34 [2] setup_top_frame(0x7fdd054c00000, 0x7fffc0, 0x7fdd0553fffc0, 0x7fdd0553fffc0, 0x0, 0xfffffe59ec25adf0), at 0x7fdd05ccdc494 [3] setup_context(0xfffffe59ec25ab10, 0x7fdd05ccdc538, 0x7fdd058492240, 0x7fdd054c00000, 0x7fffc0, 0x1), at 0x7fdd05ccdc4dc [4] _thrp_create(0x0, 0x800000, 0x1000becb0, 0x61bfa6bed0, 0x80, 0xfffffe59ec25aeb0), at 0x7fdd05ccd7f64 [5] pthread_create(0x61bfa6bed0, 0xfffffe59ec25af78, 0x1000becb0, 0x61bfa6bed0, 0x0, 0x0), at 0x7fdd05ccc80e4 [6] ldap_pvt_thread_create(0x61bfa6bed0, 0x0, 0x1000becb0, 0x61bfa6bed0, 0x0, 0x61bfa6bec0), at 0x7fdd05c81b324 [7] slapd_daemon(0x100406db8, 0x4, 0x10042710c, 0x100389490, 0x100406d38, 0x100382000), at 0x1000c1404 [8] main(0x8800, 0x10038aa88, 0x1, 0x100386038, 0x1, 0x10038aa84), at 0x10009ec34 (dbx) lwp l@3 t@3 (l@3) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x4, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd0577ff2a0, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x10, 0x7fdd0577ffc30, 0x7fdd0577ff2a0, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x10, 0x7fdd0577ffc30, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x1, 0x1004010c8, 0x5), at 0x1000c014c (dbx) lwp l@4 t@4 (l@4) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x4, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd056bff370, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x12, 0x7fdd056bffd10, 0x7fdd056bff370, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x12, 0x7fdd056bffd10, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x2, 0x1004016f0, 0x5), at 0x1000c014c (dbx) lwp l@5 t@5 (l@5) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x1, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd055fff340, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x14, 0x7fdd055fffcf0, 0x7fdd055fff340, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x14, 0x7fdd055fffcf0, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x3, 0x100401d18, 0x5), at 0x1000c014c (dbx) -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9362] New: slapd crashed with a segmentation fault in syncprov
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9362 Issue ID: 9362 Summary: slapd crashed with a segmentation fault in syncprov Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- Description of problem: Two times on slapd crashed with segmentation faults and cores were outputted. The following messages were outputted to /var/log/messages. -------------------- Jun 23 19:42:51 GC001CVFC101 kernel: slapd[1985]: segfault at 2 ip 00005647e0543414 sp 00007f6c088b5de0 error 4 in slapd[5647e04df000+1c0000] Jun 23 19:42:53 GC001CVFC101 systemd: slapd.service: main process exited, code=killed, status=11/SEGV Jun 23 19:42:53 GC001CVFC101 systemd: Unit slapd.service entered failed state. Jun 23 19:42:53 GC001CVFC101 systemd: slapd.service failed. ..... Jun 23 23:56:48 GC001CVFC101 kernel: slapd[8759]: segfault at 3 ip 000055d24efbc414 sp 00007fe9a8ffae80 error 4 in slapd[55d24ef58000+1c0000] Jun 23 23:56:49 GC001CVFC101 systemd: slapd.service: main process exited, code=killed, status=11/SEGV Jun 23 23:56:50 GC001CVFC101 systemd: Unit slapd.service entered failed state. Jun 23 23:56:50 GC001CVFC101 systemd: slapd.service failed. -------------------- The followings are the logs that are outputted to /var/log/slapd.log-20200624 Each segmentation fault occurred during modify and delete requests for ldap entries. ------------- Jun 23 19:42:50 GC001CVFC101 slapd[2281]: conn=7028108 op=391 MOD dn="uid=user,ou=users,dc=example,dc=com" ..... Jun 23 23:56:48 GC001CVFC101 slapd[32641]: conn=1552 op=144 DEL dn="cn=group1,ou=groups,dc=example,dc=com" ------------- The followings are the backtraces of two cores. 1) core-slapd.2281: -------------------- (gdb) bt #0 test_filter (op=op@entry=0x7f6c088b6130, e=0x7f6bee9e37c8, f=0x2) at filterentry.c:69 ^^^^^*1 #1 0x00007f6cb379e598 in syncprov_matchops (op=op@entry=0x7f6be01191d0, opc=opc@entry=0x7f6bec001710, saveit=saveit@entry=1) at syncprov.c:1334 #2 0x00007f6cb379ec63 in syncprov_op_mod (op=0x7f6be01191d0, rs=<optimized out>) at syncprov.c:2201 #3 0x00005647e0591e8a in overlay_op_walk (op=op@entry=0x7f6be01191d0, rs=0x7f6c088b7960, which=op_modify, oi=0x5647e1633dd0, on=0x5647e1638d00) at backover.c:661 #4 0x00005647e0592034 in over_op_func (op=0x7f6be01191d0, rs=<optimized out>, which=<optimized out>) at backover.c:730 #5 0x00005647e053b2f9 in fe_op_modify (op=0x7f6be01191d0, rs=0x7f6c088b7960) at modify.c:303 #6 0x00005647e053d2ed in do_modify (op=0x7f6be01191d0, rs=0x7f6c088b7960) at modify.c:177 #7 0x00005647e0522e7c in connection_operation (ctx=ctx@entry=0x7f6c088b7bd0, arg_v=arg_v@entry=0x7f6be01191d0) at connection.c:1158 #8 0x00005647e05231eb in connection_read_thread (ctx=0x7f6c088b7bd0, argv=0x67) at connection.c:1294 #9 0x00007f6cbaad82fa in ldap_int_thread_pool_wrapper () from debug/lib64/libldap_r-2.4.so.2 #10 0x00007f6cb9d9ae25 in start_thread (arg=0x7f6c088b8700) at pthread_create.c:308 #11 0x00007f6cb925c34d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 (gdb) -------------------- 2) core-slapd.32641 -------------------- (gdb) bt #0 test_filter (op=op@entry=0x7fe9a8ffb1d0, e=0x7fe9c7ea8888, f=0x3) at filterentry.c:69 ^^^^^*1 #1 0x00007feab3f22598 in syncprov_matchops (op=op@entry=0x7fe99c000950, opc=opc@entry=0x7fe99c001808, saveit=saveit@entry=1) at syncprov.c:1334 #2 0x00007feab3f22c63 in syncprov_op_mod (op=0x7fe99c000950, rs=<optimized out>) at syncprov.c:2201 #3 0x000055d24f00ae8a in overlay_op_walk (op=op@entry=0x7fe99c000950, rs=0x7fe9a8ffb960, which=op_delete, oi=0x55d250c54dd0, on=0x55d250c59d00) at backover.c:661 #4 0x000055d24f00b034 in over_op_func (op=0x7fe99c000950, rs=<optimized out>, which=<optimized out>) at backover.c:730 #5 0x000055d24efb6bf6 in fe_op_delete (op=0x7fe99c000950, rs=0x7fe9a8ffb960) at delete.c:174 #6 0x000055d24efb68d6 in do_delete (op=0x7fe99c000950, rs=0x7fe9a8ffb960) at delete.c:95 #7 0x000055d24ef9be7c in connection_operation (ctx=ctx@entry=0x7fe9a8ffbbd0, arg_v=arg_v@entry=0x7fe99c000950) at connection.c:1158 #8 0x000055d24ef9c1eb in connection_read_thread (ctx=0x7fe9a8ffbbd0, argv=0x3a) at connection.c:1294 #9 0x00007feabb25c2fa in ldap_int_thread_pool_wrapper () from debug/lib64/libldap_r-2.4.so.2 #10 0x00007feaba51ee25 in start_thread (arg=0x7fe9a8ffc700) at pthread_create.c:308 #11 0x00007feab99e034d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 (gdb) -------------------- The two cores seem to be the same, only the difference between modify and delete request. Both are considered to cause a segmentation fault because the value of the third parameter(*1) of test_filter is invalid. The third parameter(*1) of test_filter should be an address, like the source below. Excerpt from filterentry.c: -------------------- 60 int 61 test_filter( 62 Operation *op, 63 Entry *e, 64 Filter *f ) ** the third parameter of test_filter 65 { 66 int rc; 67 Debug( LDAP_DEBUG_FILTER, "=> test_filter\n", 0, 0, 0 ); 68 69 if ( f->f_choice & SLAPD_FILTER_UNDEFINED ) { ** referenced here 70 Debug( LDAP_DEBUG_FILTER, " UNDEFINED\n", 0, 0, 0 ); -------------------- Version-Release number of selected component (if applicable): How reproducible: Two times Steps to Reproduce: Unknown Actual results: slapd crashes with a segmentation fault and a core is outputted. Expected results: slapd doesn't crash and a core isn't outputted. Thanks! Simon -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Bug 9222] New: Fix presence list to use a btree instead of an AVL tree
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9222 Bug ID: 9222 Summary: Fix presence list to use a btree instead of an AVL tree Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- [23:34] <hyc> ok, so far heap profile shows that memory use during refresh is normal [23:35] <hyc> not wonderful, but normal. mem usage grows because we're recording the present list while receiving entries in the refresh [23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist [23:36] <hyc> which is pretty awful, considering presentlist is just a list of UUIDs [23:36] <hyc> being stored in an avl tree [23:37] <hyc> a btree would have been better here, and we could just use an unsorted segmented array [23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup records during the delete pphase [00:05] <hyc> this stuff seriously needs a rewrite [01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than 48MB of overhead [01:13] <hyc> and instead it's 3-400MB -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 9420] New: memory leak & ub in servers/slapd/modrdn.c`slap_modrdn2mods()
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9420 Issue ID: 9420 Summary: memory leak & ub in servers/slapd/modrdn.c`slap_modrdn2mods() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Created attachment 781 --> https://bugs.openldap.org/attachment.cgi?id=781&action=edit fix Hi. I have noticed 1) a memory leak in failure cleanup section of slap_modrdn2mods(): | for ( ; op->orr_modlist != NULL; op->orr_modlist = tmp ) { | tmp = op->orr_modlist->sml_next; | ch_free( op->orr_modlist ); | } this code leaks (n)values of mods. And 2) undefined behavior while scheduling delete: | (void) (*desc->ad_type->sat_equality->smr_normalize)(..., &mod_tmp->sml_nvalues[0], ...) this code doesn't respect normalization failures, and may leave garbage in nvalues[0]. I guess this is because somebody assumed normalization can't fail here, because the value has already been normalized during dnPrettyNormal. But ... normalization can fail at least because some normalizators do not abort() on memory allocation failures. Here is a patch that fixes these defects. Please, consider. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9417] New: ldapexop: exit with indeterminate status
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9417 Issue ID: 9417 Summary: ldapexop: exit with indeterminate status Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: danix800(a)gmail.com Target Milestone: --- In clients/tools/ldapexop.c:354 'main' calls 'tool_exit' with testing result of 'code' to 'LDAP_SUCCESS' as argument, but clang static analyzer finds that at line 103 if 'ldap_whoami' fails then 'main' should exit, leaving 'code' uninitialized, the test result is indeterminate. After further inspection I can conclude that 'rc' is set all the way down so I think 'tool_exit' should be called with 'rc' directly. See MR!207 for potential fix for this. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9394] New: syncprov: Session log can end up with duplicate entries
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9394 Issue ID: 9394 Summary: syncprov: Session log can end up with duplicate entries Product: OpenLDAP Version: 2.4.55 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Had an incident today where slapd stopped after the following assert was triggered in syncprov.c: 1655 rc = tavl_insert( &sl->sl_entries, se, syncprov_sessionlog_cmp, avl_dup_error ); 1656 assert( rc == LDAP_SUCCESS ); This was due to the same entry being inserted into the sessionlog a second time without the prior instance having been removed. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2020