- openldap-bugs - openldap.org

Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com 01 Jul '07

01 Jul '07

<quote who="Hallvard B Furuseth"> > ghenry(a)suretecsystems.com writes: >>> I have time, a manpage fix doesn't require testing:-) I'm just unsure >>> what it should say. Pierangelo's latest message kind of implied that >>> it >>> can be used with older overlays but not newer ones. >>> Should we say which ones? > > Well, yes. Shouldn't suddenly tell people they shouldn't be doing what > they are doing in cases when it's all right. But I don't know which > ones. Ping Pierangelo? > > -- > Hallvard >

1 0

Re: Tranlucent Overlay (ITS#4889)
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

ghenry(a)suretecsystems.com writes: >> I have time, a manpage fix doesn't require testing:-) I'm just unsure >> what it should say. Pierangelo's latest message kind of implied that it >> can be used with older overlays but not newer ones. >> Should we say which ones? Well, yes. Shouldn't suddenly tell people they shouldn't be doing what they are doing in cases when it's all right. But I don't know which ones. -- Hallvard

1 0

Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com 01 Jul '07

01 Jul '07

<quote who="Hallvard B Furuseth"> > Gavin Henry writes: >> True. Also, when I raised this ticket I wasn't part of the team, so I >> can take on the man page fix if Hallvard doesn't have time. > > I have time, a manpage fix doesn't require testing:-) I'm just unsure > what it should say. Pierangelo's latest message kind of implied that it > can be used with older overlays but not newer ones. Should we say which ones? > > -- > Regards, > Hallvard >

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

I wonder if we've been waiting for each other... Anyway, I've committed some pending fixes now that HEAD passes all tests for me. I've some more cleanup, but if we are close to a freeze I don't know if that means I should rush it in or wait until afterwards. >> We did have code which compared thread IDs with '==' for >> quite some time. Do you remember if anyone complained, or if the >> switch to using ldap_pvt_thread_equal() was a "just in case" fix? > > Yes, I needed to use pthread_equal() on OS/390 since their thread type > was a structure. I'm not sure, but I gather that's derived from the DCE threads reference implementation where pthread_t has three members 'field1', 'field2' and 'field3'. tls.c can't stuff all of them in a long, so the old one may not get a unique ID. OTOH DCE has a pthread_getunique_np() call which uses just the 2nd field as a unique integer thread ID, I expect we could use that. Except I don't have a host to test such a change on. Dunno why pthread_equal checks all three fields. I've asked on comp.programming.threads. Also I note that the DCE struct will get four padding bytes on a 64-bit host which aligns the struct at 8*n addresses, and the compiler is not obliged to preserve these during struct copy. On the other hand DCE threads are based on an extremely outdated Posix draft, so I don't know how relevant it is now. Another time when tls.c code loses information is if pointers are wider than long, which does happen. (Don't know how it is nowadays, but I remember plenty of postings about it some years ago.) [Using address of the thread's stack] >>> That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. As modified by PTHREAD_STACK_MIN and pthread_attr_getguardsize(). And slight other variations, apparently. I tried on a few hosts and Solaris would a few times use some extra space near the stack of a thread or two. OTOH we could allocate stack memory ourselves and then use pthread_attr_setstack() to put the stack just where we want it. However this doesn't help tls.c with threads that have been created by _other_ packages. And the SSL id_callback function apparently has no way to return failure:-( All in all I still like a thread-specific key better - they are the standard way of doing things like this. We only need it for pthreads since the other thread types as far as I can tell have integer IDs. >>> It's really >>> not hard. If we were to disallow increasing the number of threads at >>> runtime, we could simply allocate a block of thread stacks all at once, >>> which would then allow our thread IDs to be simple integers from 0-N. IIRC disallowing that would fix some other tpool problem too, but I don't remember what. >> Hmm. I asked the wrong question, should have read some man pages first. >> Still, thr_cthreads.c & thr_lwp.c don't use LDAP_PVT_THREAD_STACK_SIZE. >> man pthread_attr_getstacksize says it sets the _minimum_ stack size, but >> perhaps several M is large enough that one can expect it won't get >> multiples of that. > > That kinda implies that no one has been using the cthreads or lwp support > recently, since I doubt their default stack size would work with back-bdb's > filterindex demands. Which led me to notice that the setstacksize call now _decreases_ the stack size on some hosts. I don't suppose that was intentional, so I guess it should be size_t cursize; if( pthread_attr_getstacksize( &attr, &cursize ) || cursize < LDAP_PVT_THREAD_STACK_SIZE ) pthread_attr_setstacksize( &attr, LDAP_PVT_THREAD_STACK_SIZE ); in thr_posix and I don't know what in other thr_* files. A RE24 change I guess, since reduces the max number of threads before slapd gets into trouble. -- Regards, Hallvard

1 0

Re: Tranlucent Overlay (ITS#4889)
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

Gavin Henry writes: > True. Also, when I raised this ticket I wasn't part of the team, so I > can take on the man page fix if Hallvard doesn't have time. I have time, a manpage fix doesn't require testing:-) I'm just unsure what it should say. Pierangelo's latest message kind of implied that it can be used with older overlays but not newer ones. -- Regards, Hallvard

1 0

Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com 01 Jul '07

01 Jul '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: > >> Depends on the time you have I suppose. >> >> I presume this isn't the case in 2.4? >> >> If so, maybe we should use your first sentence and refer them to 2.4? > > Referring people to 2.4 really isn't nice unless we have an actual release > to > refer them to. Which is another reason we need to get a 2.4 beta out ASAP. True. Also, when I raised this ticket I wasn't part of the team, so I can take on the man page fix if Hallvard doesn't have time. > Since it looks like no activity has occurred on closing out the remaining > devel > ITSs perhaps we should just freeze the current tree and roll out 2.4.5 > as-is. I think that would peak users interest again too. > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >

1 0

(ITS#5035) Warning patrol
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

Full_Name: Hallvard B Furuseth Version: RE23, HEAD OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard #1. slapd/frontend.c:frontend_init() has the statement if ( slap_known_controls ) which is always true since slap_known_controls is an array. Maybe it should be if ( slap_known_controls[0] )? Except... controls.c says slap_known_controls[0] == NULL, which is not true - at least not at the time of the if-test above. What's that about? #2. The return value from op->o_callback->sc_cleanup() is never used. Should it be? I noticed because the pcache_op_cleanup() function does not return anything. What should it return? #3. RE23 struct sync_cookie.rid and struct syncinfo_s.si_rid are 'long', but are printed as 'int'. Could change the formats, but - any reason not to instead change their types to 'int' as in HEAD? I haven't looked at the HEAD syncrepl changes, so I don't know what other issues might be involved. #4. bconfig.c: Integer overflow in (1 << (sizeof(int)*8 - 1)) in slap_loglevel_get(). If anything else have been trusting signed integer overflow to resemble unsigned integers, it's time to cease that. The behaviour is undefined, and compilers make use of this fact to optimize. The loglevel functions are confused about types anyway. They collect masks in slap_mask_t, but the API uses an int for the masks. Either the API should use slap_mask_t or masks should be stored in (unsigned) ints. Not for 2.3, I think. #5. RE23 slurpd/st.c passes a time_t* to lutil_atol() which expects a long*. #6. ldbm_db_errcall() has wrong prototype for DB >= 4.3. Uses void(const DB_ENV *, const char *, char *) for DB_VERSION_X >= 0x040300, I guess it should copy back-bdb and (a) use const char* for last param and (b) test for DB_VERSION_FULL instead. Better late than never, I guess... #7. Other format bugs: - slapd/daemon.c: SLAP_EVENT_FD(i) is a ptrdiff_t printed as int. I take it SLAP_EPOLL_EV_PTRFD() should return a ber_socket_t like in its 'sl_sd' branch. - libldap/request.c: LDAP* given to %p should be cast to void*. #7. "Real" warnings drown in void* = function* warnings. Someday I want to go through the code and fill in (void*) casts. That doesn't make the code more standard, but can shut up compilers. I don't know if this should be imported to RE23 - maybe the chance of a new typo is greater than the chance of uncovering a bug:-)

1 0

Re: Tranlucent Overlay (ITS#4889)
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

hyc(a)symas.com writes: > Referring people to 2.4 really isn't nice unless we have an actual > release to refer them to. Which is another reason we need to get a 2.4 > beta out ASAP. Since it looks like no activity has occurred on > closing out the remaining devel ITSs perhaps we should just freeze the > current tree and roll out 2.4.5 as-is. I'm working through some new and a few old issues now, as it happens. But I don't see any reason why that needs to hold up a beta. There's always time for another beta. -- Regards, Hallvard

1 0

Re: Tranlucent Overlay (ITS#4889)
by hyc＠symas.com 01 Jul '07

01 Jul '07

ghenry(a)suretecsystems.com wrote: > Depends on the time you have I suppose. > > I presume this isn't the case in 2.4? > > If so, maybe we should use your first sentence and refer them to 2.4? Referring people to 2.4 really isn't nice unless we have an actual release to refer them to. Which is another reason we need to get a 2.4 beta out ASAP. Since it looks like no activity has occurred on closing out the remaining devel ITSs perhaps we should just freeze the current tree and roll out 2.4.5 as-is. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5034) ldapsearch -E not in manpage
by zhangweiwu＠realss.com 01 Jul '07

01 Jul '07

在 2007-07-01日的 10:11 +0200，Hallvard B Furuseth写道： > zhangweiwu(a)realss.com writes: > > The -E option in ldapsearch is not mentioned in ldapsearch manual, > > It is now, since OpenLDAP 2.3.28 I think. Maybe you've got older > manuals than binaries, or multiple OpenLDAP installations. Yes you are right. 2.3.27 version on SuSE has this option missing in manual, but 2.3.30 on Gentoo Linux have this option in manual. My mistake on not checking carefully the newer version. Thanks for closing this issue.

1 0

Re: Tranlucent Overlay (ITS#4889)
by ghenry＠suretecsystems.com 01 Jul '07

01 Jul '07

<quote who="Hallvard B Furuseth"> > Gavin Henry writes: >><quote who="Pierangelo Masarati"> >>> In re23 slapo-rwm should not be used in conjunction with other >>> overlays; there is a number of reports about interoperability issues, >>> (...) >> That's strange though, as I merely followed the slapd-ldap(5) man page: >> (...) >> Maybe a man page patch is needed to stop others hitting this. > > I'll insert "OpenLDAP 2.3, rwm should not be used in conjunction with > other overlays." in slapo-rwm(5), slapd-ldap(5) and slapd-relay(5) > unless someone has a better idea. > > Or since Pierangelo followed up with > "it interacts poorly with other, more recent overlays." If you stop ^^ here, then you might as well use your first sentence. > should it be "...unless you know what you are doing" in the backend docs > and a more detailed instruction in slapo-rwm(5)? Depends on the time you have I suppose. I presume this isn't the case in 2.4? If so, maybe we should use your first sentence and refer them to 2.4? > > -- > Regards, > Hallvard >

1 0

Re: (ITS#5034) ldapsearch -E not in manpage
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

zhangweiwu(a)realss.com writes: > The -E option in ldapsearch is not mentioned in ldapsearch manual, It is now, since OpenLDAP 2.3.28 I think. Maybe you've got older manuals than binaries, or multiple OpenLDAP installations. -- Regards, Hallvard

1 0

Re: Tranlucent Overlay (ITS#4889)
by h.b.furuseth＠usit.uio.no 01 Jul '07

01 Jul '07

Gavin Henry writes: ><quote who="Pierangelo Masarati"> >> In re23 slapo-rwm should not be used in conjunction with other >> overlays; there is a number of reports about interoperability issues, >> (...) > That's strange though, as I merely followed the slapd-ldap(5) man page: > (...) > Maybe a man page patch is needed to stop others hitting this. I'll insert "OpenLDAP 2.3, rwm should not be used in conjunction with other overlays." in slapo-rwm(5), slapd-ldap(5) and slapd-relay(5) unless someone has a better idea. Or since Pierangelo followed up with "it interacts poorly with other, more recent overlays." should it be "...unless you know what you are doing" in the backend docs and a more detailed instruction in slapo-rwm(5)? -- Regards, Hallvard

1 0

(ITS#5034) ldapsearch -E not in manpage
by zhangweiwu＠realss.com 01 Jul '07

01 Jul '07

Full_Name: Zhang Weiwu Version: 2.3.35-r1 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.61.17.143) The -E option in ldapsearch is not mentioned in ldapsearch manual, as I have tested on both openSuSE 10.2 and gentoo Linux. Unfortunately I don't know what it means but it seems to be pretty useful and enabled extended search filter like given in RFC 3876. Probably it means "extend filter", I guess. An example of -E as being discussed on openldap-software list: when I search with "cn=foo*", and entry has multiple "cn" values, like "cn=foo", "cn=joe", "cn=foobar", "cn=foobarX", "cn=bob", "cn=nofoobar" doing this search, it should only return "cn=foo", "cn=foobar", "cn=foobarX", $ ldapsearch -E mv="(cn=foo*)"

1 0

(ITS#5033) make depend breaks if configure doesn't know how
by h.b.furuseth＠usit.uio.no 30 Jun '07

30 Jun '07

Full_Name: Hallvard B Furuseth Version: RE23, HEAD OS: HP-UX URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard If configure does not know how to make dependencies, it still asks us to run make depend. On HP-UX, that miscompile OpenLDAP. In addition to fixing the "please run make depend" message, I suggest: In build/openldap.m4, set OL_MKDEP= either ":" or "false". - ":" allows autobuild scripts that run "make depend" to work. - "false" warns people who do use "make depend" that build - modify source - rebuild may not work. I've got no strong preference. Will use ":" if nobody disagrees.

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by h.b.furuseth＠usit.uio.no 30 Jun '07

30 Jun '07

Howard Chu writes: > Strange. It all builds perfectly fine on my SuSE 9.2 x86_64 system. At > this point it's getting rather monotonous pointing out how much RedHat > gets wrong... For a chance, this doesn't look like a RedHat problem. It's not their fault that libtool mistranslates perfectly good -l<lib> command line options. OTOH, they did install db-4.3, so it's not as I'll be using it anyway. But I imagine I may run into the same problem with other /lib64/ libraries. -- Regards, Hallvard

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by hyc＠symas.com 30 Jun '07

30 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, HEAD > OS: RedHat Linux/x86_64 > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > libtool translates -ldb-4.3 to /usr/lib/libdb-4.3.so, which breaks. > "cc -ldb-4.3" uses /lib64/libdb-4.3.so. > > Looks like the fix is to upgrade to libtool-1.5.24. Its NEWS says > * Search paths with GCC on multilib systems like x86_64 have been fixed. > > I haven't checked how to upgrade, though. Tried to install a private > libtool and run libtoolize, but it just said "You should update > your `aclocal.m4' by running aclocal" even after I ran aclocal. Strange. It all builds perfectly fine on my SuSE 9.2 x86_64 system. At this point it's getting rather monotonous pointing out how much RedHat gets wrong... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5032) cannot build on x86_64, needs newer libtool
by h.b.furuseth＠usit.uio.no 30 Jun '07

30 Jun '07

Full_Name: Hallvard B Furuseth Version: RE23, HEAD OS: RedHat Linux/x86_64 URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard libtool translates -ldb-4.3 to /usr/lib/libdb-4.3.so, which breaks. "cc -ldb-4.3" uses /lib64/libdb-4.3.so. Looks like the fix is to upgrade to libtool-1.5.24. Its NEWS says * Search paths with GCC on multilib systems like x86_64 have been fixed. I haven't checked how to upgrade, though. Tried to install a private libtool and run libtoolize, but it just said "You should update your `aclocal.m4' by running aclocal" even after I ran aclocal.

1 0

Re: (ITS#5031) Question about transaction in OpenLDAP
by ghenry＠suretecsystems.com 28 Jun '07

28 Jun '07

<quote who="lixin922(a)huawei.com"> > Full_Name: lixin > Version: OpenLDAP2.4.4alpha > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.21.230.126) > > > Hello, > > I have known that the OpenLDAP2.4 will support transaction from > roadmap.Now I am > testing OpenLDAP2.4.4alpha,But I am not sure whether this version suports > transation.If it supports how to use it.If not,about which version will > support > it,and when this version will appear. > > Thank you very much. Hi, Our ITS system is for reporting and tracking OpenLDAP bugs. Since you are asking a question that should be asked on openldap-software(a)openldap.org, this ITS will be closed. Kindly re-send your question to the correct list. Gavin.

1 0

(ITS#5031) Question about transaction in OpenLDAP
by lixin922＠huawei.com 28 Jun '07

28 Jun '07

Full_Name: lixin Version: OpenLDAP2.4.4alpha OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.21.230.126) Hello, I have known that the OpenLDAP2.4 will support transaction from roadmap.Now I am testing OpenLDAP2.4.4alpha,But I am not sure whether this version suports transation.If it supports how to use it.If not,about which version will support it,and when this version will appear. Thank you very much.

1 0

(ITS#5030) Setting/knowing max query size
by bruno_haleblian＠carrefour.com 27 Jun '07

27 Jun '07

Full_Name: Bruno Version: 2.3.21 OS: redhat AS 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.77.224.130) Hi, I am looking for a way to limit ldap query size - there may be one in slapd.conf but I could not find it yet(still reading). Sometimes slapd process crashes because of malformed - too lenghty requests. While this is due to a buggy EAI updater which will be fixed - I still think it should be safer to limit this size from server side. thanks

1 0

Re: (ITS#5028) incomplete slapcat docs
by ghenry＠suretecsystems.com 26 Jun '07

26 Jun '07

<quote who="h.b.furuseth(a)usit.uio.no"> > hyc(a)symas.com writes: >> steve(a)stevenwills.com wrote: >>> The slapcat man page says in the Limitations section: >>> >>> In general, your slapd(8) should not be running (at least, not >>> in >>> read-write mode) when you do this to ensure consistency of the >>> database. >>> (...) >> Given that back-ldbm has been deleted for 2.4, I guess we can just >> delete this sentence. > > It could produce garbage data with back-ldif, and with some foreign > database module. I think it should say it's safe with bdb (and null). > Could copy it to the slapd-bdb(5) too. (I don't suggest to make > slapcat(8) refer the user to that, since there is only one example > anyway.) Obviously hdb too. Would it produce garbage on 2.4? > > -- > Regards, > Hallvard > > >

1 0

Re: (ITS#5028) incomplete slapcat docs
by ghenry＠suretecsystems.com 26 Jun '07

26 Jun '07

<quote who="hyc(a)symas.com"> > steve(a)stevenwills.com wrote: >> Full_Name: Steve Wills >> Version: 2.3.19 >> OS: Fedora >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (65.15.231.202) >> >> >> The slapcat man page says in the Limitations section: >> >> In general, your slapd(8) should not be running (at least, not in >> read-write mode) when you do this to ensure consistency of the database. >> >> However, I've been told several times that this only applies to ldbm and >> not >> bdb. Not sure about other types, but it would be good to clarify this >> section. >> > Given that back-ldbm has been deleted for 2.4, I guess we can just delete > this > sentence. I would agree. > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: (ITS#5028) incomplete slapcat docs
by h.b.furuseth＠usit.uio.no 26 Jun '07

26 Jun '07

hyc(a)symas.com writes: > steve(a)stevenwills.com wrote: >> The slapcat man page says in the Limitations section: >> >> In general, your slapd(8) should not be running (at least, not in >> read-write mode) when you do this to ensure consistency of the database. >> (...) > Given that back-ldbm has been deleted for 2.4, I guess we can just > delete this sentence. It could produce garbage data with back-ldif, and with some foreign database module. I think it should say it's safe with bdb (and null). Could copy it to the slapd-bdb(5) too. (I don't suggest to make slapcat(8) refer the user to that, since there is only one example anyway.) -- Regards, Hallvard

1 0

Re: (ITS#5029) refint schema unavailable
by hyc＠symas.com 26 Jun '07

26 Jun '07

dirk.a.schaefer(a)bluewin.ch wrote: > Full_Name: Dirk Alexander Scheafer > Version: openldap-2.3.35-r1 > OS: gentoo 2007.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.3.4.29) > > > i have all my openldap configuration within it's internal cn=config db, > slapd.conf has been removed. i use several overlays where refint is one of them. > after slapd has started, the refint specific attributes and objectclass are not > available, not visible within the schema. > > by this, the refint overlay is not usable for my installation but there is no > error shown anywhere, regardless at which debug/log level the server is beeing > executed. This is a known limitation in 2.3, fixed in 2.4. In fact this condition is logged both to stderr and to syslog: config_build_entry: "olcDatabase={1}bdb" WARNING: No dynamic config support for overlay refint. config_build_entry: "olcOverlay={0}refint" config_build_entry: "olcDatabase={2}monitor" This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

feature --enable-ppolicy
by Philippe Radix 26 Jun '07

26 Jun '07

hello I try to test the new feature the new version openldap (openldap-2.3.36) cd /alcatel/PR/ tar xvzf openldap-2.3.36.tgz cd /alcatel/PR/openldap-2.3.36 ./configure --prefix=/opt/ldap/OpenLDAP --with-cyrus-sasl --with-tls --enable-backends --enable-overlays make depend make make install i create slapd.cond --------------- vi slapd.conf include /opt/ldap/OpenLDAP/etc/openldap/schema/core.schema include /opt/ldap/OpenLDAP/etc/openldap/schema/ppolicy.schema include /opt/ldap/OpenLDAP/etc/openldap/schema/cosine.schema include /opt/ldap/OpenLDAP/etc/openldap/schema/inetorgperson.schema overlay ppolicy ppolicy_default "cn=StandardPolicy,ou=Policies,dc=alcatel,dc=com" ppolicy_use_lockout pidfile /alcatel/openldapTest/slapd.pid argsfile /alcatel/openldapTest/slapd.args database bdb suffix "dc=alcatel,dc=com" rootdn "cn=Admin,dc=alcatel,dc=com" directory /alcatel/openldapTest/data by self write by anonymous auth by * none access to * by self write by anonymous auth by * read i create defaultpolicy ------------------ dn: ou=Policies,dc=alcatel,dc=com objectClass: top objectClass: organizationalUnit ou: Policies structuralObjectClass: organizationalUnit dn: cn=StandardPolicy,ou=Policies,dc=alcatel,dc=com objectClass: top objectClass: device objectClass: pwdPolicy cn: StandardPolicy pwdAttribute: userPassword pwdLockoutDuration: 120 pwdInHistory: 5 pwdCheckQuality: 2 pwdExpireWarning: 86400 pwdMaxAge: 864000 pwdMinLength: 5 pwdGraceAuthNLimit: 5 pwdAllowUserChange: TRUE pwdMustChange: FALSE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: FALSE structuralObjectClass: device i create user ------------ dn:cn=prtest,dc=alcatel,dc=com sn: prtest userpassword: prtest objectClass: person pwdPolicySubentry: cn=StandardPolicy cn: prtest i thinl all are ok for the policies features but and i run server ldap -------------- and i want to change password with a bad policy password ldappasswd -h 192.200.244.87 -p 389 -x -D cn=prtest,dc=alcatel,dc=com -w prtest -s titi -e ppolicy i have Result: Success (0) as answer i dont arive to see the policyies error with client ldap could you help me regards -- ************************************************************ Philippe Radix Alcatel CIT (philippe.radix(a)alcatel-lucent.fr) Tel.: (33) 01 3077 2829

2 1

Re: (ITS#5028) incomplete slapcat docs
by hyc＠symas.com 26 Jun '07

26 Jun '07

steve(a)stevenwills.com wrote: > Full_Name: Steve Wills > Version: 2.3.19 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.15.231.202) > > > The slapcat man page says in the Limitations section: > > In general, your slapd(8) should not be running (at least, not in > read-write mode) when you do this to ensure consistency of the database. > > However, I've been told several times that this only applies to ldbm and not > bdb. Not sure about other types, but it would be good to clarify this section. > Given that back-ldbm has been deleted for 2.4, I guess we can just delete this sentence. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5029) refint schema unavailable
by dirk.a.schaefer＠bluewin.ch 25 Jun '07

25 Jun '07

Full_Name: Dirk Alexander Scheafer Version: openldap-2.3.35-r1 OS: gentoo 2007.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.3.4.29) i have all my openldap configuration within it's internal cn=config db, slapd.conf has been removed. i use several overlays where refint is one of them. after slapd has started, the refint specific attributes and objectclass are not available, not visible within the schema. by this, the refint overlay is not usable for my installation but there is no error shown anywhere, regardless at which debug/log level the server is beeing executed. greez d. a. schaefer

1 0

(ITS#5028) incomplete slapcat docs
by steve＠stevenwills.com 25 Jun '07

25 Jun '07

Full_Name: Steve Wills Version: 2.3.19 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.15.231.202) The slapcat man page says in the Limitations section: In general, your slapd(8) should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. However, I've been told several times that this only applies to ldbm and not bdb. Not sure about other types, but it would be good to clarify this section.

1 0

(ITS#5027) loglevel if none specified
by steve＠stevenwills.com 25 Jun '07

25 Jun '07

Full_Name: Steve Wills Version: 2.3.19 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.15.231.202) The slapd.conf man page says that if no log level is specified, no logging is done: In fact, if no loglevel (or a 0 level) is defined, no logging occurs, so at least the none level is required to have high priority messages logged. However, in my experience, with this configuration in my syslog: local4.* /var/log/ldap.log a great deal of logging is done. This seems inconsistent. Either the docs or the code are incorrect. Which is right?

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by luca＠OpenLDAP.org 25 Jun '07

25 Jun '07

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: > >> ando(a)sys-net.it writes: >> >>> I'm seeing occasional failures of syncrepl-related tests in HEAD. In >>> case of test043, results differend once, but after repeating the test >>> everything went smoth. >>> >> Six HEAD/test043-delta-syncrepl failures in a row. Producer and >> consumer databases differ. RedHat Linux, i686. Logs etc from testrun: >> ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070621.tgz >> >> > Strange, I saw some failures last week but with current HEAD it just works. > Nevermind. I just checked out a fresh copy from CVS and it works just fine. Maybe something fancy with some modifications I was testing. I'll have to check.

1 0

RE: (ITS#5026) LDAP Search very slow > 2mins
by quanah＠zimbra.com 22 Jun '07

22 Jun '07

--On Friday, June 22, 2007 6:55 AM +0000 andy.yip(a)newworldtel.com wrote: > Dear sir, > > We found the ldap search is slow running. Please advise how to fine tune > the database. I am not sure adding cache size or perform db_recover will > solve the problem (a) This is not the place to discuss how to tune openldap (b) You have not indicated a valid OpenLDAP version, and in fact, give the impression that you are using Sun DS not OpenLDAP. That means *we* cannot help you. (c) If you *are* using OpenLDAP, go use openldap-software(a)openldap.org to ask your questions, as you were already told to do. Supply a *valid* OpenLDAP version. Further emails to this ITS will be ignored. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by luca＠OpenLDAP.org 22 Jun '07

22 Jun '07

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: > >> ando(a)sys-net.it writes: >> >>> I'm seeing occasional failures of syncrepl-related tests in HEAD. In >>> case of test043, results differend once, but after repeating the test >>> everything went smoth. >>> >> Six HEAD/test043-delta-syncrepl failures in a row. Producer and >> consumer databases differ. RedHat Linux, i686. Logs etc from testrun: >> ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070621.tgz >> >> > Strange, I saw some failures last week but with current HEAD it just works. > > I just uploaded my test files ftp://ftp.openldap.org/incoming/Luca_Scamoni-070622.tgz The difference here is also in the modifyTimestamp and modifiersName...

1 0

RE: (ITS#5026) LDAP Search very slow > 2mins
by andy.yip＠newworldtel.com 22 Jun '07

22 Jun '07

Dear sir, We found the ldap search is slow running. Please advise how to fine tune the database. I am not sure adding cache size or perform db_recover will solve the problem Regards, Andy -----Original Message----- From: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Wednesday, June 20, 2007 10:39 PM To: Yip S C, Andy (NS NWT) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#5026) LDAP Search very slow > 2mins Please take this to the mailinglist openldap-software(a)openldap.org. The ITS system is for bug reports, feature requests etc. This ITS will be closed. Note however that there never was an OpenLDAP version 1.8.8.7. So I wonder if your trouble is with a Sun LDAP server instead. -- Regards, Hallvard

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by hyc＠symas.com 22 Jun '07

22 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I'm seeing occasional failures of syncrepl-related tests in HEAD. In >> case of test043, results differend once, but after repeating the test >> everything went smoth. > > Six HEAD/test043-delta-syncrepl failures in a row. Producer and > consumer databases differ. RedHat Linux, i686. Logs etc from testrun: > ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070621.tgz > Strange, I saw some failures last week but with current HEAD it just works. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by h.b.furuseth＠usit.uio.no 21 Jun '07

21 Jun '07

ando(a)sys-net.it writes: > I'm seeing occasional failures of syncrepl-related tests in HEAD. In > case of test043, results differend once, but after repeating the test > everything went smoth. Six HEAD/test043-delta-syncrepl failures in a row. Producer and consumer databases differ. RedHat Linux, i686. Logs etc from testrun: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070621.tgz -- Regards, Hallvard

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 21 Jun '07

21 Jun '07

h.b.furuseth(a)usit.uio.no wrote : >That's from ITS#4975: The code was broken for builds without TLS. >It's been fixed in HEAD. Does it work now? Hi Hallvard, Yes I confirm that the problem with TLS compilation is fixed now. But the main problem of this ITS still remains (replica seg faults if syncrepl searchbase =""). Sorry for this late answer. Best regards Ali

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

Pierangelo Masarati wrote: > Simon Gao wrote: > > >> OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no >> longer crashes. You can go ahead close 5022 and 5023. >> > > OK. Then I think the different behavior at different loglevel was > actually a side effect of something related to ITS#4964. > > >> Should I also update provider to 2.3.36? >> > > AFAIK, no. Please make sure that the password change, besides > succeeding, is correctly replicated. While fixing ITS#4964, a companion > bug in the provider was discovered, but it appeared to be related to > code development that's not in the 2.3 release (ITS#4973). > > Replications works fine. I tries changing password 5 or 6 times, replication worked each time. I will hold on upgrading provider for now. Thanks again. Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it 20 Jun '07

20 Jun '07

Simon Gao wrote: > OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no > longer crashes. You can go ahead close 5022 and 5023. OK. Then I think the different behavior at different loglevel was actually a side effect of something related to ITS#4964. > Should I also update provider to 2.3.36? AFAIK, no. Please make sure that the password change, besides succeeding, is correctly replicated. While fixing ITS#4964, a companion bug in the provider was discovered, but it appeared to be related to code development that's not in the 2.3 release (ITS#4973). Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

Pierangelo Masarati wrote: > gao(a)schrodinger.com wrote: > > >> slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' >> failed. >> > > __Could__ be the same as ITS#4964, which was fixed in OpenLDAP 2.3.36 > just released, apart from depending on the log level, which I definitely > consider odd. > > Can you check if the problem persists with the latest release? > > OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no longer crashes. You can go ahead close 5022 and 5023. Should I also update provider to 2.3.36? Thanks, Simon

1 0

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 20 Jun '07

20 Jun '07

Hi Howard, I've reduced the threads to 4 (number of cpus), and I still get frequent coredumps: #0 0xa83ba58a in strcasecmp () from /lib/libc.so.6 [New Thread 0x9e31800 (LWP 100335)] [New Thread 0x81eb500 (LWP 100316)] [New Thread 0x8188a00 (LWP 100185)] [New Thread 0x81cff00 (LWP 100146)] [New Thread 0x81c9800 (LWP 100069)] [New Thread 0x813a000 (LWP 100626)] (gdb) bt #0 0xa83ba58a in strcasecmp () from /lib/libc.so.6 #1 0x080a93d0 in an_find (a=0xa81b6f0, s=0x830b2a4) at ad.c:842 #2 0x080d5a41 in add_filter_attrs (op=0xa78a800, new_attrs=0xbf1fc8c4, attrs=0x81863e0, filter_attrs=0x830b27c, fattr_cnt=3, fattr_got_oc=0) at pcache.c:1140 #3 0x080d6260 in pcache_op_search (op=0xa78a800, rs=0xbf1fcd70) at pcache.c:1313 #4 0x080c8401 in overlay_op_walk (op=0xa78a800, rs=0xbf1fcd70, which=op_search, oi=0x813ae00, on=0x813af00) at backover.c:498 #5 0x080c861d in over_op_func (op=0xa78a800, rs=0xbf1fcd70, which=op_search) at backover.c:560 #6 0x080c869a in over_op_search (op=0xa78a800, rs=0xbf1fcd70) at backover.c:582 #7 0x0806ec33 in fe_op_search (op=0xa78a800, rs=0xbf1fcd70) at search.c:355 #8 0x0806e752 in do_search (op=0xa78a800, rs=0xbf1fcd70) at search.c:217 #9 0x0806c1b7 in connection_operation (ctx=0xbf1fce00, arg_v=0xa78a800) at connection.c:1133 #10 0xa816be00 in ldap_int_thread_pool_wrapper (xpool=0x8148340) at tpool.c:478 #11 0xa830e5cf in pthread_create () from /usr/lib/libthr.so.2 #12 0x00000000 in ?? () > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 20, 2007 10:02 AM > To: Imri Zvik > Cc: openldap-its(a)openldap.org > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > It appears that your system has simply run out of memory, most likely > because > you have 34 active threads in the process. That's far too many threads > for a > typical 32 bit machine. > > Imri Zvik ( Smile ) wrote: > > I have new tar.gz file ready, this time with unstripped binaries: > > http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz > > > > root@cemetery:~$ ldd /usr/local/libexec/slapd > > /usr/local/libexec/slapd: > > libldap_r-2.3-releng.so.2 => > > /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000) > > liblber-2.3-releng.so.2 => > > /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000) > > libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000) > > libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000) > > libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000) > > libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000) > > libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000) > > libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000) > > libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000) > > libc.so.6 => /lib/libc.so.6 (0xa8319000) > > root@cemetery:~$ file /usr/local/libexec/slapd > > /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386, > > version 1 (FreeBSD), dynamically linked (uses shared libs), not > stripped > > > > Please let me know if there is anything else you need, > > > > --imriz > > > > > >> -----Original Message----- > >> From: Howard Chu [mailto:hyc@symas.com] > >> Sent: Tuesday, April 03, 2007 12:42 AM > >> To: Imri Zvik ( Smile ) > >> Cc: openldap-its(a)openldap.org > >> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > >> > >> imriz(a)co.zahav.net.il wrote: > >>> Sure. New core dumps and binary file is at > >>> http://mariska.inter.net.il/~imriz/slapd-core.tar.gz > >> The slapd in this snapshot was stripped so no debug symbols are > >> present. > >> Please be sure to use an unstripped binary. > >> > >> Also, since you're also loading libldap_r, liblber, back-ldap, back- > >> bdb, > >> back-meta, and back-ldbm dynamically, you'll need to include those > >> modules in the tarball. (Also with debug and unstripped.) > >> > >> Although at this point I'm wondering why you're using back-ldbm, > which > >> has been deprecated for quite a long time. > >> > >>> Please notice that the previous dump was from FreeBSD ports > > (OpenLDAP > >>> version 2.3.33). > >>> > >>> This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > >>> following configure options: > >>> > >>> ./configure --with-threads=posix --with-tls=openssl --enable- > dynamic > >>> --without-cyrus-sasl --enable-modules --localstatedir=/var/ > >>> db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable- > >> ldap=mod > >>> --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > >>> e-monitor=mod --enable-proxycache --disable-syncprov > > --enable-bdb=mod > >>> --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > >>> prefix=/usr/local --enable-debug > >>> > >>> > >>> -----Original Message----- > >>> From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > >>> Sent: Tuesday, February 13, 2007 1:14 AM > >>> To: Imri Zvik > >>> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > >>> > >>> It looks like this core is from a binary without debug symbols > >> present, > >>> can you > >>> recompile with debugging enabled and get a new stack trace and core > >>> file? > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5026) LDAP Search very slow > 2mins
by h.b.furuseth＠usit.uio.no 20 Jun '07

20 Jun '07

Please take this to the mailinglist openldap-software(a)openldap.org. The ITS system is for bug reports, feature requests etc. This ITS will be closed. Note however that there never was an OpenLDAP version 1.8.8.7. So I wonder if your trouble is with a Sun LDAP server instead. -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 20 Jun '07

20 Jun '07

About context_reset() in pool_wrapper(): Yes, it works out. Anyway I completely lost that kfree functions may not lock ltp_mutex since it's already locked (again unless they go active). Will just document that they may not call functions which take a pool argument anyway - they can only use the context. Will also insert various asserts about how the pool should be used (pause/pause etc.) Another detail: tpool.c tracks task counts as 'long's, but pool_query() and pool_backload() return them in 'int's. Can use int counts instead and set a max pending limit of INT_MAX - LDAP_MAXTHR. -- Regards, Hallvard

1 0

(ITS#5026) LDAP Search very slow > 2mins
by andy.yip＠newworldtel.com 20 Jun '07

20 Jun '07

Full_Name: Andy Yip Version: 1.8.8.7 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.98.135.2) We found ldap_search runs very slow.We's like to know how to fine tune the database. Please help

1 0

Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by hyc＠symas.com 20 Jun '07

20 Jun '07

It appears that your system has simply run out of memory, most likely because you have 34 active threads in the process. That's far too many threads for a typical 32 bit machine. Imri Zvik ( Smile ) wrote: > I have new tar.gz file ready, this time with unstripped binaries: > http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz > > root@cemetery:~$ ldd /usr/local/libexec/slapd > /usr/local/libexec/slapd: > libldap_r-2.3-releng.so.2 => > /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000) > liblber-2.3-releng.so.2 => > /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000) > libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000) > libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000) > libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000) > libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000) > libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000) > libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000) > libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000) > libc.so.6 => /lib/libc.so.6 (0xa8319000) > root@cemetery:~$ file /usr/local/libexec/slapd > /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386, > version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped > > Please let me know if there is anything else you need, > > --imriz > > >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Tuesday, April 03, 2007 12:42 AM >> To: Imri Zvik ( Smile ) >> Cc: openldap-its(a)openldap.org >> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) >> >> imriz(a)co.zahav.net.il wrote: >>> Sure. New core dumps and binary file is at >>> http://mariska.inter.net.il/~imriz/slapd-core.tar.gz >> The slapd in this snapshot was stripped so no debug symbols are >> present. >> Please be sure to use an unstripped binary. >> >> Also, since you're also loading libldap_r, liblber, back-ldap, back- >> bdb, >> back-meta, and back-ldbm dynamically, you'll need to include those >> modules in the tarball. (Also with debug and unstripped.) >> >> Although at this point I'm wondering why you're using back-ldbm, which >> has been deprecated for quite a long time. >> >>> Please notice that the previous dump was from FreeBSD ports > (OpenLDAP >>> version 2.3.33). >>> >>> This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the >>> following configure options: >>> >>> ./configure --with-threads=posix --with-tls=openssl --enable-dynamic >>> --without-cyrus-sasl --enable-modules --localstatedir=/var/ >>> db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable- >> ldap=mod >>> --enable-meta=mod --enable-rewrite --enable-null=mod --enabl >>> e-monitor=mod --enable-proxycache --disable-syncprov > --enable-bdb=mod >>> --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- >>> prefix=/usr/local --enable-debug >>> >>> >>> -----Original Message----- >>> From: Howard Chu [mailto:openldap-its@OpenLDAP.org] >>> Sent: Tuesday, February 13, 2007 1:14 AM >>> To: Imri Zvik >>> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) >>> >>> It looks like this core is from a binary without debug symbols >> present, >>> can you >>> recompile with debugging enabled and get a new stack trace and core >>> file? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

Pierangelo Masarati wrote: > gao(a)schrodinger.com wrote: > > >> slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' >> failed. >> > > __Could__ be the same as ITS#4964, which was fixed in OpenLDAP 2.3.36 > just released, apart from depending on the log level, which I definitely > consider odd. > > Can you check if the problem persists with the latest release? > > I will. Probably I will get back you tomorrow. Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it 20 Jun '07

20 Jun '07

gao(a)schrodinger.com wrote: > slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' > failed. __Could__ be the same as ITS#4964, which was fixed in OpenLDAP 2.3.36 just released, apart from depending on the log level, which I definitely consider odd. Can you check if the problem persists with the latest release? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

Quanah Gibson-Mount wrote: > --On Tuesday, June 19, 2007 9:38 PM -0700 Simon Gao > <gao(a)schrodinger.com> wrote: > >> I take back what I said in my last email. When compiled with "-ggdb", >> slapd on consumer server still crashes while running: > > Compile with -g, not -ggdb. > > And when you "make install", slapd generally gets stripped, which is > why there is still no really useful info. You need to run make > install STRIP="" > Yes, I generated first coredump with "-g". If "-ggdb" is not helpful, please forget it. I used "FEATURES="nostrip" emerge --buildpkgonly <package>" to compile new OpenLDAP binaries with "-g" option. Then untar it to a temp directory. This way there is no stripping occurred. So here is coredump when slapd is compile with "-g": ==================================================================================== # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213049168 (LWP 28621)] [New Thread -1240032368 (LWP 28624)] [New Thread -1248425072 (LWP 28625)] [New Thread -1256817776 (LWP 28626)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1248425072 (LWP 28625)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7b4f429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7b509d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7b48e51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response (op=0x827c760, rs=0xb59681b4) at result.c:364 berbuf = { buffer = "\002\000\001\000\000\000\000\000????\000\000\000\000\000\000\000\000\\Pv?\\Pv?8`v?<`v?\000\000\000\000H\212&\b", '\0' <repeats 211 times>, ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0xb5967a18 rc = <value optimized out> bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x08080caf in slap_send_ldap_extended (op=0x827c760, rs=0xb59681b4) at result.c:630 No locals. #6 0x080fa450 in ldap_chain_response (op=0x827c760, rs=0xb59681b4) ---Type <return> to continue, or q <return> to quit--- at chain.c:920 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}f5kiigYucjOHoM0r9zDuwW0GjxVa9y1h"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} ---Type <return> to continue, or q <return> to quit--- lb = {lb_status = LDAP_CH_NONE, lb_lc = 0x820dd60, lb_op_f = 0, lb_depth = 0} sc = (slap_callback *) 0xb596811c sc2 = {sc_next = 0x0, sc_response = 0x80fa782 <ldap_chain_cb_response>, sc_cleanup = 0, sc_private = 0xb5967cbc} rc = 80 text = 0x0 matched = 0x0 ref = (BerVarray) 0x8279b18 sr_err = 10 sr_type = REP_EXTENDED #7 0x080c73e5 in over_back_response (op=0x827c760, rs=0xb59681b4) at backover.c:236 on = (slap_overinst *) 0x820dc60 rc = 0 be = (BackendDB *) 0x820e330 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}f5kiigYucjOHoM0r9zDuwW0GjxVa9y1h"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} #8 0x080803ee in send_ldap_response (op=0x827c760, rs=0xb59681b4) at result.c:303 sc = (slap_callback *) 0xb596811c sc_prev = (slap_callback **) 0xb5967f48 sc_next = (slap_callback *) 0x0 berbuf = { buffer = "\035\000\000\000\000\000\000\000????\000\000\000\000????\006-\v\bh?'\b?~\226?\030\223%\b\000\000\000\000\000\000\000\000\b\021!\b", '\0' <repeats 13---Type <return> to continue, or q <return> to quit--- times>, "? \bh?'\b\030\233'\b\020?'\b8? \b\000\000\000\000\034\201\226?us\f\b", '\0' <repeats 28 times>, "`?'\b?\201\226?h?'\b\n\000\000\000|?'\b\204?'\b`?'\bC\025\n\b<Pv?H\212&\b\000\000\000\000????\205?\023\b", '\0' <repeats 24 times>, "?\201\226?\234?'\b\224?'\b", '\0' <repeats 16 times>, "\027\000\000\000??'\b\001\000\000\000d\201\226?\000"..., ialign = 29, lalign = 29, falign = 4.06376555e-44, dalign = 1.432790372939615e-322, palign = 0x1d <Address 0x1d out of bounds>} ber = <value optimized out> rc = -1024 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #9 0x08080caf in slap_send_ldap_extended (op=0x827c760, rs=0xb59681b4) at result.c:630 No locals. #10 0x0809ff84 in fe_extended (op=0x827c760, rs=0xb59681b4) at extended.c:230 bd = (BackendDB *) 0xb596801c ext = (struct extop_list *) 0x81af248 #11 0x080c74d0 in overlay_op_walk (op=0x827c760, rs=0xb59681b4, which=op_extended, oi=0x820db60, on=0x820dc60) at backover.c:508 sc_next = <value optimized out> rc = 32768 #12 0x080c783b in over_op_func (op=0x827c760, rs=0xb59681b4, which=op_extended) at backover.c:560 oi = (slap_overinfo *) 0x820db60 ---Type <return> to continue, or q <return> to quit--- on = (slap_overinst *) 0x820dc60 be = (BackendDB *) 0x8188200 db = {bd_info = 0x8188100, be_ctrls = "\000", '\001' <repeats 13 times>, '\0' <repeats 18 times>, be_flags = 769, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81dec78, be_nsuffix = 0x81deca0, be_schemadn = {bv_len = 12, bv_val = 0x8211140 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x8210f00 "cn=subschema"}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = { bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81826c4, be_private = 0x0, be_next = {stqe_next = 0x81dfff0}} cb = {sc_next = 0x0, sc_response = 0x80c7375 <over_back_response>, ---Type <return> to continue, or q <return> to quit--- sc_cleanup = 0, sc_private = 0x820db60} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #13 0x080a04b8 in do_extended (op=0x827c760, rs=0xb59681b4) at extended.c:180 reqdata = {bv_len = 22, bv_val = 0x827c9d8 "0\024\201\bpiThid6i"} len = 22 #14 0x0806f701 in connection_operation (ctx=0xb5968238, arg_v=0x827c760) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_EXTENDED, sr_tag = 120, sr_msgid = 2, sr_err = 10, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 32} tag = 119 opidx = SLAP_OP_EXTENDED conn = (Connection *) 0xb616b598 memctx = (void *) 0x8268a48 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #15 0xb7f83bb1 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #16 0xb5968238 in ?? () No symbol table info available. #17 0x0827c760 in ?? () No symbol table info available. #18 0xb7fb0024 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #19 0xb5968238 in ?? () No symbol table info available. #20 0xb7fb0020 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #21 0x081cb96c in ?? () No symbol table info available. #22 0x081cb954 in ?? () No symbol table info available. #23 0x00000000 in ?? () No symbol table info available. ============================================================================================ Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by quanah＠zimbra.com 20 Jun '07

20 Jun '07

--On Tuesday, June 19, 2007 9:38 PM -0700 Simon Gao <gao(a)schrodinger.com> wrote: > I take back what I said in my last email. When compiled with "-ggdb", > slapd on consumer server still crashes while running: Compile with -g, not -ggdb. And when you "make install", slapd generally gets stripped, which is why there is still no really useful info. You need to run make install STRIP="" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

I take back what I said in my last email. When compiled with "-ggdb", slapd on consumer server still crashes while running: ldappasswd -v -H ldap://ldap2.example.com -D "uid=user,ou=people,dc=example,dc=com" -W -S -x -A Here is coredump with "-ggdb" if helpful: ======================================================================================= # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213368656 (LWP 6060)] [New Thread -1240351856 (LWP 6063)] [New Thread -1248744560 (LWP 6064)] [New Thread -1257137264 (LWP 6065)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1257137264 (LWP 6065)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7b01429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7b029d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7afae51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response (op=0x82640d8, rs=0xb51191b4) at result.c:364 berbuf = { buffer = "\002\000\001\000\000\000\000\000????\000\000\000\000\000\000\000\000\\\200\201?\\\200\201?8\220\201?<\220\201?\000\000\000\000?_%\b", '\0' <repeats 211 times>, ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0xb5118a18 rc = <value optimized out> bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x08080caf in slap_send_ldap_extended (op=0x82640d8, rs=0xb51191b4) at result.c:630 No locals. #6 0x080fa450 in ldap_chain_response (op=0x82640d8, rs=0xb51191b4) ---Type <return> to continue, or q <return> to quit--- at chain.c:920 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}*******************************"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} ---Type <return> to continue, or q <return> to quit--- lb = {lb_status = LDAP_CH_NONE, lb_lc = 0x820dd60, lb_op_f = 0, lb_depth = 0} sc = (slap_callback *) 0xb511911c sc2 = {sc_next = 0x0, sc_response = 0x80fa782 <ldap_chain_cb_response>, sc_cleanup = 0, sc_private = 0xb5118cbc} rc = 80 text = 0x0 matched = 0x0 ref = (BerVarray) 0x8266fd0 sr_err = 10 sr_type = REP_EXTENDED #7 0x080c73e5 in over_back_response (op=0x82640d8, rs=0xb51191b4) at backover.c:236 on = (slap_overinst *) 0x820dc60 rc = 0 be = (BackendDB *) 0x820e330 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}********************************"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} #8 0x080803ee in send_ldap_response (op=0x82640d8, rs=0xb51191b4) at result.c:303 sc = (slap_callback *) 0xb511911c sc_prev = (slap_callback **) 0xb5118f48 sc_next = (slap_callback *) 0x0 berbuf = { buffer = "\035\000\000\000\000\000\000\000????\000\000\000\000????\006-\v\b??%\b?\216\021?\030\223%\b\000\000\000\000\000\000\000\000\b\021!\b", '\0' <repeats---Type <return> to continue, or q <return> to quit--- 13 times>, "? \b??%\b?o&\b\230?'\b8? \b\000\000\000\000\034\221\021?us\f\b", '\0' <repeats 28 times>, "?@&\b?\221\021???%\b\n\000\000\000?@&\b?@&\b?@&\bC\025\n\b<\200\201??_%\b\000\000\000\000????\205?\023\b", '\0' <repeats 24 times>, "?\221\021?\024A&\b\fA&\b", '\0' <repeats 16 times>, "\027\000\000\000??'\b\001\000\000\000d\221\021?\000"..., ialign = 29, lalign = 29, falign = 4.06376555e-44, dalign = 1.432790372939615e-322, palign = 0x1d <Address 0x1d out of bounds>} ber = <value optimized out> rc = -1024 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #9 0x08080caf in slap_send_ldap_extended (op=0x82640d8, rs=0xb51191b4) at result.c:630 No locals. #10 0x0809ff84 in fe_extended (op=0x82640d8, rs=0xb51191b4) at extended.c:230 bd = (BackendDB *) 0xb511901c ext = (struct extop_list *) 0x81af248 #11 0x080c74d0 in overlay_op_walk (op=0x82640d8, rs=0xb51191b4, which=op_extended, oi=0x820db60, on=0x820dc60) at backover.c:508 sc_next = <value optimized out> rc = 32768 #12 0x080c783b in over_op_func (op=0x82640d8, rs=0xb51191b4, which=op_extended) at backover.c:560 oi = (slap_overinfo *) 0x820db60 on = (slap_overinst *) 0x820dc60 ---Type <return> to continue, or q <return> to quit--- be = (BackendDB *) 0x8188200 db = {bd_info = 0x8188100, be_ctrls = "\000", '\001' <repeats 13 times>, '\0' <repeats 18 times>, be_flags = 769, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81dec78, be_nsuffix = 0x81deca0, be_schemadn = {bv_len = 12, bv_val = 0x8211140 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x8210f00 "cn=subschema"}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = { bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81826c4, be_private = 0x0, be_next = {stqe_next = 0x81dfff0}} cb = {sc_next = 0x0, sc_response = 0x80c7375 <over_back_response>, sc_cleanup = 0, sc_private = 0x820db60} ---Type <return> to continue, or q <return> to quit--- rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #13 0x080a04b8 in do_extended (op=0x82640d8, rs=0xb51191b4) at extended.c:180 reqdata = {bv_len = 22, bv_val = 0x827bbc0 "0\024\201\bpiThid6i"} len = 22 #14 0x0806f701 in connection_operation (ctx=0xb5119238, arg_v=0x82640d8) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_EXTENDED, sr_tag = 120, sr_msgid = 2, sr_err = 10, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 32} tag = 119 opidx = SLAP_OP_EXTENDED conn = (Connection *) 0xb611d598 memctx = (void *) 0x8255fb8 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #15 0xb7f35bb1 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #16 0xb5119238 in ?? () ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #17 0x082640d8 in ?? () No symbol table info available. #18 0xb7f62024 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #19 0xb5119238 in ?? () No symbol table info available. #20 0xb7f62020 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #21 0x081cb96c in ?? () No symbol table info available. #22 0x081cb954 in ?? () No symbol table info available. #23 0x00000000 in ?? () No symbol table info available. =================================================================================================== Simon

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs