Full_Name: Konrad Windszus Version: 2.4.40 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.61.79.222) Running the overlays ppolicy and rwm on OpenLDAP 2.4.40 (RPM from http://ltb-project.org/) and executing a bind request on the mapped area leads to a segmentation fault. This is the stacktrace from GDB Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ff1f61a4700 (LWP 22660)] 0x0000000000000012 in ?? () (gdb) bt #0 0x0000000000000012 in ?? () #1 0x0000000000505dc0 in hdb_reader_get (op=op@entry=0x7ff1ec000980, env=0x11fa840, txn=txn@entry=0x7ff1f61a30e0) at cache.c:1673 #2 0x000000000050e5ea in hdb_entry_get (op=0x7ff1ec000980, ndn=0x7ff1ec0009b8, oc=0x0, at=0x0, rw=0, ent=0x7ff1f61a3398) at id2entry.c:349 #3 0x00000000004a4cba in overlay_entry_get_ov (op=0x7ff1ec000980, dn=0x7fecec0009b8, oc=0x0, ad=0x0, rw=0, e=0x7ff1f61a3398, on=<optimized out>) at backover.c:364 #4 0x00000000004a4d27 in over_entry_get_rw (op=<optimized out>, dn=<optimized out>, oc=<optimized out>, ad=<optimized out>, rw=<optimized out>, e=<optimized out>) at backover.c:396 #5 0x00000000005528a7 in ppolicy_bind_response (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at ppolicy.c:924 #6 0x000000000044edb6 in slap_response_play (op=op@entry=0x7ff1ec000980, rs=rs@entry=0x7ff1f61a39a0) at result.c:508 #7 0x000000000044f2c7 in send_ldap_response (op=op@entry=0x7ff1ec000980, rs=rs@entry=0x7ff1f61a39a0) at result.c:583 #8 0x000000000044fc62 in slap_send_ldap_result (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at result.c:861 #9 0x000000000045c239 in fe_op_bind_success (op=op@entry=0x7ff1ec000980, rs=rs@entry=0x7ff1f61a39a0) at bind.c:441 #10 0x000000000045c8fd in fe_op_bind (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at bind.c:386 #11 0x000000000045c041 in do_bind (op=0x7ff1ec000980, rs=0x7ff1f61a39a0) at bind.c:205 #12 0x000000000044032e in connection_operation (ctx=ctx@entry=0x7ff1f61a3ad0, arg_v=arg_v@entry=0x7ff1ec000980) at connection.c:1155 #13 0x000000000044060a in connection_read_thread (ctx=0x7ff1f61a3ad0, argv=0xc) at connection.c:1291 #14 0x000000000058da59 in ldap_int_thread_pool_wrapper (xpool=0x113cee0) at tpool.c:688 #15 0x00007ff1fab7ddf3 in start_thread (arg=0x7ff1f61a4700) at pthread_create.c:308 #16 0x00007ff1f99e201d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 As soon as the overlay ppolicy is disabled, the crash is gone.
On Tue, 14 Oct 2014 15:31:25 +0000 konrad.windszus@netcentric.biz wrote > As soon as the overlay ppolicy is disabled, the crash is gone. Can you also please try whether the order of slapo-rwm and slapo-ppolicy makes any difference? Ciao, Michael.
We use two backends 1) Is leveraging ppolicy with an hdb backend 2) Is leveraging rwm with a relay backend (relaying to 1) with a different suffix Therefore we cannot influence the order. Modifying the loading order of the overlays did result in exactly the same stacktrace.
changed notes
moved from Incoming to Software Bugs
probably needs ITS#6166 (bind response) See also ITS#7384
Needs testing to see if this still occurs
*** This issue has been marked as a duplicate of issue 9871 ***