Pierangelo Masarati a écrit :

...

I've tested your latest commit, and most of our tests now run great. However, I still get a segault with the two rules below. Please note that this segfault only happens when *both* rules are present, each one by itself does not cause a segfault :

...

access to dn.sub="ou=Affectations,dc=linagora,dc=org" attrs=sigleAbrege,labeledURI,mailRoutingAddress,telephoneNumber,facsimileTelephoneNumber,entry by set="([ldap:///] + (([ldap:///] + ((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-0)

• [??base?])/responsable) +

[??base?(|(administrateurResponsable=] + user + [)(administrateur=] + user + [)(membre=] + user + [))])/entryDN" +rscx by * break access to dn.sub="ou=Affectations,dc=linagora,dc=org" attrs=domaineMessagerie,finValidite,identifiantHarpegeStructure,responsable,objectClass,entry by set="[ldap:///] + (((([ldap:///] + this + [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-100) & ((([ldap:///] + user + [??base?(objectClass=personnel)])/entryDN)/-100)) + [??sub?entryDN=] + user/entryDN" +rscx by * break

I'm afraid that we use quite a few specific schemas so you may not be able to reproduce this easily. However, I hope these rules will enable you to determine the problematic case. If necessary, I could prepare a data and schema extract to reproduce the problem.

That would help, but before you do it, could you please post a backtrace of the stack when the issue occurs? In case this doesn't suffice, and I can't figure things out myself, I'll ask you to provide a self-contained set of data that causes the issue.

Of course. Please also see my message a few minutes ago with valgrind output. Stack trace follows:

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1740719216 (LWP 10412)] 0xb7bcfdec in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7bcfdec in free () from /lib/tls/i686/cmov/libc.so.6 #1 0x0816338e in ber_bvarray_free_x (a=0x82e4058, ctx=0x82bd6b8) at memory.c:731 #2 0x080af40a in slap_set_filter (gatherer=0x8086720 <acl_set_gather>, cp=0x983291e0, fbv=0x983291e8, user=0x82dc094, target=0xb5312bd0, results=0x0) at sets.c:391 #3 0x080864ca in acl_match_set (subj=0x983295b0, op=0x82dbff8, e=0xb5312bc4, default_set_attribute=0x0) at acl.c:2299 #4 0x08089786 in slap_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at acl.c:1621 #5 0x0808b6c4 in fe_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at acl.c:311 #6 0x080c8930 in over_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at backover.c:314 #7 0x080872c4 in access_allowed_mask (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=<value optimized out>, state=0x0, maskp=0x0) at acl.c:413 #8 0x08083bcf in test_ava_filter (op=0x82dbff8, e=0xb5312bc4, ava=0x97eeb4bc, type=163) at filterentry.c:545 #9 0x080843e9 in test_filter (op=0x82dbff8, e=0xb5312bc4, f=0x97eeb4e4) at filterentry.c:88 #10 0x080dc90e in bdb_search (op=0x82dbff8, rs=0x983eb154) at search.c:844 #11 0x080679f6 in fe_op_search (op=0x82dbff8, rs=0x983eb154) at search.c:368 #12 0x080c7ca1 in overlay_op_walk (op=0x82dbff8, rs=0x983eb154, which=op_search, oi=0x8264bf8, on=0x8264cf8) at backover.c:652 #13 0x080c820d in over_op_func (op=0x82dbff8, rs=0x983eb154, which=op_search) at backover.c:704 #14 0x0806823e in do_search (op=0x82dbff8, rs=0x983eb154) at search.c:217 #15 0x0806583e in connection_operation (ctx=0x983eb238, arg_v=0x82dbff8) at connection.c:1145 #16 0x08065c71 in connection_read_thread (ctx=0x983eb238, argv=0xe) at connection.c:1271 #17 0x0813cda6 in ldap_int_thread_pool_wrapper (xpool=0x824bfd0) at tpool.c:614 #18 0xb7cab31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #19 0xb7c3457e in clone () from /lib/tls/i686/cmov/libc.so.6

Regards, Jon