Full_Name: Alan Sparks Version: 1.2.1 stable OS: HP/UX 10.20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.114.2.83) Originally observed using GQ client in browse mode. Can be duplicated using the command: ldapsearch -b "cn=config" -s base 'objectclass=*' Slapd built with HP/UX 10.20, GCC 2.8.1 and libstdc 2.8.1.1. Slapd dumps core immediately on receiving the above query, with the stack trace: #0 0xc00d3ca0 in regexec () #1 0x1fae4 in acl_get_applicable (be=0x2, op=0x40007b28, e=0x400051e8, attr=0x8e18 "entry", nmatch=10, matches=0x7b03b020) at acl.c:134 #2 0x1f68c in access_allowed (be=0x40006fe8, conn=0x4000a250, op=0x40005120, e=0x400051e8, attr=0x8e18 "entry", val=0x0, access=8) at acl.c:70 #3 0x1a014 in send_search_entry (be=0x40006fe8, conn=0x4000a250, op=0x40005120, e=0x400051e8, attrs=0x0, attrsonly=0) at result.c:196 #4 0x23bd4 in config_info (conn=0x4000a250, op=0x40005120) at configinfo.c:66 #5 0x13fb0 in do_search (conn=0x4000a250, op=0x40005120) at search.c:152 #6 0x134b0 in connection_operation (arg_v=0x0) at connection.c:86 #7 0x353d4 in ldap_pvt_thread_create (thread=0x0, detach=0, start_routine=0, arg=0x7b03b020) at thr_stub.c:40 #8 0x13970 in connection_activity (conn=0x4000a250) at connection.c:207 #9 0x12e84 in slapd_daemon (port=0x0) at daemon.c:362 #10 0x353d4 in ldap_pvt_thread_create (thread=0x0, detach=0, start_routine=0, arg=0x7b03b020) at thr_stub.c:40 #11 0x11748 in main (argc=3, argv=0x7b03a2dc) at main.c:202 Logging with loglevel 2+4+256 shows: Apr 21 21:20:38 mercury slapd[17575]: conn=0 op=1 SRCH base="CN=CONFIG" scope=0 filter="(objectclass=*)" Apr 21 21:20:38 mercury slapd[17575]: => send_search_entry (CN=CONFIG) Apr 21 21:20:38 mercury slapd[17575]: => acl_get: edn Apr 21 21:20:38 mercury slapd[17575]: => acl_get: [1] check attr entry Apr 21 21:20:38 mercury slapd[17575]: => dnpat: [2] .* nsub: 0
Alan, I'm not exactly sure what the problem is here, but... >#0 0xc00d3ca0 in regexec () >#1 0x1fae4 in acl_get_applicable (be=0x2, op=0x40007b28, e=0x400051e8, > attr=0x8e18 "entry", nmatch=10, matches=0x7b03b020) at acl.c:134 >#2 0x1f68c in access_allowed (be=0x40006fe8, conn=0x4000a250, op=0x40005120, > e=0x400051e8, attr=0x8e18 "entry", val=0x0, access=8) at acl.c:70 be=0x2 ? Seems that something trashed the Backend (be) pointer and the Operation (op) pointers. I suspect the regexec call has trashed the stack. You might want to check the REGEX library and make sure it implements POSIX 1003.2 regular expressions. You may want to try a third party Posix REGEX library (Henry Spencer's, GNU regex, or GNU rx). Poking about in the debugger might provide additional hints as to what the problem is. Kurt
Hello, I've similar problem. We're using OpenLDAP 1.2.0 on Solaris 2.6 with gcc 2.8.1. >You might want to check the REGEX library and make sure it >implements POSIX 1003.2 regular expressions. You may want >to try a third party Posix REGEX library (Henry Spencer's, >GNU regex, or GNU rx). I installed rx-1.5 and recompile OpenLDAP. Then we got error during make tests: ... >>>>> Starting test006-acls ... Cleaning up in ./test-db... Running ldif2ldbm to build slapd database... Starting slapd on TCP/IP port 9009... Testing slapd access control... Waiting 5 seconds for slapd to start... Using ldapsearch to retrieve all the entries... Comparing database to reference file ./test-db/ldapsearch.out ./data/acl.out.master differ: char 788, line 26 comparison failed - modify operations did not complete correctly >>>>> ./scripts/test006-acls failed (exit 1) make: *** [all-local] Error 1 Would anyone please advise ? Thanks a lot. Regards, ST Wong
moved from Incoming to Software Bugs
Have you resolved this issue on your own? Kurt
changed state Open to Feedback
On Mon, 24 May 1999, Kurt Zeilenga wrote: > Have you resolved this issue on your own? > > Kurt Not at this time. -Alan
moved from Software Bugs to Incoming
changed notes
changed notes changed state Feedback to Closed
Forwarded to ITS#136 to help the next poor soul. At 10:20 AM 6/7/99 -0700, Alan Sparks wrote: >Couple of notes on Release 1.2.3... >Build environment: HP/UX 10.20, GCC 2.8.1, Sleepycat db-2.7.5... > >ITS #136 (coredump on cn=config) does /not/ seem to happen anymore under >this build environment. Perhaps this issue can be closed (since I submitted >it, it's OK by me :-). I'm just now thinking that this problem may have been due to a bad REGEX library as was found on Solaris 2.4. (Ie: some versions of HP-UX may also have a bad REGEX library). If you run into this one again, try using a replacement REGEX. http://www.openldap.org/faq/index.cgi?file=152
close at submitter's request.