[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Test fails on Solaris 2.4 (ITS#104)

Kurt Zeilenga writes:
> Would be interested to know if your problems persist with 1.2.2
OK, after installing gdb-4.18 (very surprised it wasn't there)
I had a look at the core dump, and my intuition (that it had to
do with regular expressions) proved to be right:

Core was generated by `../servers/slapd/slapd -f ./data/slapd-master.conf -p 9009 -d 5'.
(gdb) bt
#0  0xef5f7fd4 in __regexec_C () from /usr/lib/libc.so.1
#1  0x26a3c in test_substring_filter (be=0xef109240, conn=0x0, op=0x0, 
    e=0xef109240, f=0xef10923c) at filterentry.c:412
#2  0x25a64 in test_filter (be=0x9d990, conn=0xa59b8, op=0x9f858, e=0x14ce18, 
    f=0x12a7c8) at filterentry.c:48
#3  0x26258 in test_filter_list (be=0x9d990, conn=0xa59b8, op=0x9f858, 
    e=0x14ce18, flist=0x12a7c8, ftype=160) at filterentry.c:266
#4  0x25d6c in test_filter (be=0x9d990, conn=0xa59b8, op=0x9f858, e=0x14ce18, 
    f=0xa4618) at filterentry.c:81
#5  0x351d4 in ldbm_back_search (be=0x9d990, conn=0xa59b8, op=0x9f858, 
    base=0xa8e80 "O=UNIVERSITY OF MICHIGAN,C=US", scope=2, deref=0, 
    slimit=500, tlimit=3600, filter=0xa4618, 
    filterstr=0x9f8b0 "(&(objectclass=RFC822MAILGROUP)(cn=A*))", attrs=0x0, 
    attrsonly=0) at search.c:210
#6  0x1c830 in do_search (conn=0xa59b8, op=0x9f858) at search.c:149
#7  0x1bc80 in connection_operation (arg_v=0xa52b0) at connection.c:74
(gdb) up
#1  0x26a3c in test_substring_filter (be=0xef109240, conn=0x0, op=0x0, 
    e=0xef109240, f=0xef10923c) at filterentry.c:412
412                     rc = !regexec(&re, realval, 0, NULL, 0);
(gdb) p re
$1 = {re_nsub = 0}
(gdb) p realval
$2 = 0xef109240 "ALL STAFF"

Now on Solaris 2.6 we have this:

C Library Functions                                   regcomp(3C)
     regcomp, regexec, regerror,  regfree  -  regular  expression
     #include <sys/types.h>
     #include <regex.h>
     int regcomp(regex_t *preg, const char *pattern, int cflags);
     int regexec(const regex_t *preg, const char *string,
          size_t nmatch, regmatch_t pmatch[], int eflags);
     size_t regerror(int errcode, const regex_t *preg,
          char *errbuf, size_t errbuf_size);
     void regfree(regex_t *preg);

and on Solaris 2.4:

regcmp(3G)             C Library Functions             regcmp(3G)
     regcmp, regex - compile and execute regular expression
     cc [ flag ... ] file ...  -lgen [ library ... ]
     #include <libgen.h>
     char *regcmp(const char *string1, /* char *string2 */ ... ,
          int /*(char *)0*/);
     char *regex(const char *re, const char *subject,
          /* char *ret0 */ ... );
     extern char *__loc1;
     regcmp()  compiles  a  regular expression (consisting of the
     concatenated arguments) and returns a pointer  to  the  com-
     piled form.  malloc(3C) is used to create space for the com-
     piled  form.   It  is  the  user's  responsibility  to  free
     unneeded  space  so  allocated.  A NULL return from regcmp()
     indicates an incorrect argument.  regcmp(1) has been written
     to generally preclude the need for this routine at execution

Maybe I should use a different regex package, as suggested in


GNU regex 0.12 OK?

Are there provisions in OpenLDAP to use that instead of the
system version?