openldap-bugs January 2021

openldap-bugs@openldap.org

1 participants
300 discussions

Start a nNew thread

[Issue 7295] Problem with TLS: threads and OpenSSL
by openldap-its＠openldap.org 25 Jan '21

25 Jan '21

1 0

[Issue 7295] Problem with TLS: threads and OpenSSL
by openldap-its＠openldap.org 25 Jan '21

25 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=7295 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |libraries Target Milestone|2.5.1 |2.5.3 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fix: mutex call gets moved into slapd so that the library doesn't change the mutexes by itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 25 Jan '21

25 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ |reviewed -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 25 Jan '21

25 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.1 |2.6.0 Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6830] slapo-ppolicy.5 has incorrect schema fragments
by openldap-its＠openldap.org 25 Jan '21

25 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=6830 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |reviewed -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6830] slapo-ppolicy.5 has incorrect schema fragments
by openldap-its＠openldap.org 25 Jan '21

25 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=6830 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.1 |2.5.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 7926] modifying olcListenerThreads crashes slapd
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=7926 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stacey.marshall(a)gmail.com --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9340 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

[Issue 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9098 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |OL_2_5_REQ Target Milestone|2.4.52 |2.5.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2021