- openldap-bugs - openldap.org

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by rein＠OpenLDAP.org 08 Jun '09

08 Jun '09

michael(a)stroeder.com wrote: > Found 6 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) Do you have the entire output from the test script? It is required to tell what actually went wrong, and without it I'm tempted to assume it failed due to some timing glitch within the test script itself.. Rein

1 0

(ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 08 Jun '09

08 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard send_ldap_ber() has a suspicious-looking waitloop doing this: if ( ldap_pvt_thread_mutex_trylock( &conn->c_mutex )) { ldap_pvt_thread_mutex_unlock( &conn->c_write1_mutex ); ldap_pvt_thread_mutex_lock( &conn->c_write1_mutex ); Unlock does not mean a thread waiting for c_write1_mutex will acquire it immediately. Such a thread may have to wait until it is scheduled, at which time the looping thread has locked the mutex again. On the Linux box on my desk, a pure unlock-lock loop goes through 50000-100000 iterations before another thread waiting for the lock acquires it. OTOH, on a heavily used box it takes ~50 iterations. A sched_yield() between the unlock and lock reduces #iterations to 1. No idea if that is the right solution, nor how serious the problem is. The lock/unlock statements themselves are from result.c rev 1.323, but then with some more locking between them which disappeared in later revisions. My lock-unlock test program: #include <pthread.h> #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <sys/select.h> static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; static unsigned count; static void *waiter(void *arg) { pthread_mutex_lock(&m); printf("Locked after %u iterations.\n", count); exit(0); } int main() { pthread_t t; pthread_mutex_lock(&m); pthread_create(&t, NULL, waiter, NULL); select(0, NULL, NULL, NULL, &(struct timeval){0, 100000}); for (count = 1 ;; ++count) { pthread_mutex_unlock(&m); pthread_mutex_lock(&m); } }

1 0

(ITS#6163) back-sql DoS when searching for empty attr
by karavelov＠spnet.net 08 Jun '09

08 Jun '09

Full_Name: Luben Karavelov Version: 2.4.11-15 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.83.96.32) We use ldap for some user accounts authentication here and we have found that queries of this kind : ldapsearch -b "dc=users,dc=example,dc=com" "(&(objectClass=posixAccount)(uid=))" kill slapd. It exits on assert( 0 ) at line 1366 of back-sql/search.c It is even nastier because it could be remotely triggered with ssh -l "" server-with-ldap-accounts-in-nss.example.com or through ftp using the same technique.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 08 Jun '09

08 Jun '09

Kurt Zeilenga wrote: > > On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >> Updated schema file cosine-update.schema attached. > > I note that differs are generally preferred, even where the file is > mostly changed. This helps ensure changes that others might make to the > file you started with are not lost. I thought about sending a diff but the file in this form is more readable for easy review. Could someone please look at it whether that's ok? Another approach would be to have two schema files, one which only contains the schema descriptions from RFC 4524 and one with the missing schema descriptions from RFC 1274 with the latter obviously being dependent on the former. >> IPR notice: >> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >> 1274. All of the modifications to OpenLDAP Software represented in the >> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >> I have not assigned rights and/or interest in this work to any party. > > While this notice of origin is fine, you did not include a rights > statement. I, Michael Ströder, hereby place the modified schema file cosine.schema attached to ITS#6151 (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.

1 0

(ITS#6162) hexadecimal log levels are not recognized in configuration
by jonathan＠phillipoux.net 08 Jun '09

08 Jun '09

Full_Name: Jonathan Clarke Version: RE24 and HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-bconfig-20090608.patch Submission from: (NULL) (80.65.230.146) The slapd-config(5) and slapd.conf(5) man pages state: olcLogLevel: <integer> [...] The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation [...] as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, This is not the case. Integers and names (strings) are accepted, but hex notation is refused, with, from slapd.conf: /opt/openldap-RE24/etc/openldap/slapd.conf: line 10: <loglevel> unable to parse level "0x40" And using ldapmodify on cn=config: ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcLogLevel> unable to parse level Hexadecimal values are, however, accepted as arguments to the -d argument to slapd on the command line. The above patch fixes bconfig.c to accept hex values. On a side note, according to man strtol(3), this also means that loglevels can be typed in octal, for the more masochist among us :)

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Download content of directory testrun/ here: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz I cannot reproduce this within directory tests/. It usually ends with this message: ERROR: Entry not removed on central search! Race error found after 1 of 10 iterations Found 3 errors >>>>>> Exiting with a false success status for now

1 0

(ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.113.91) Found 6 errors >>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) make[2]: *** [hdb-mod] Error 6 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 05 Jun '09

05 Jun '09

Hrmph, the placement of the 'so->s_op->o_abandon = 1;' which I wanted to move out of the mutex lock derives from syncprov.c rev 1.20 commented "Fix abandon sequencing":-( -- Hallvard

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by quanah＠zimbra.com 05 Jun '09

05 Jun '09

--On Friday, June 05, 2009 9:25 PM +0100 Gavin Henry <gavin.henry(a)gmail.com> wrote: > Is there a SEE ALSO? > > Will check and amend. Regardless of SEE ALSO, it should note that it indexes the database while adding it. ;) SEE ALSO ldap(3), ldif(5), slapcat(8), ldapadd(1), slapd(8) Should probably have slapindex in the SEE ALSO as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by gavin.henry＠gmail.com 05 Jun '09

05 Jun '09

Is there a SEE ALSO? Will check and amend. On 05/06/2009, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The man page for slapadd does not note that it also performs indexing while > adding the database. While this is fairly obvious to those of us > experienced > with using OpenLDAP, it is non-obvious to new users. > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6160) slapadd man page doesn't note indexing
by quanah＠OpenLDAP.org 05 Jun '09

05 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The man page for slapadd does not note that it also performs indexing while adding the database. While this is fairly obvious to those of us experienced with using OpenLDAP, it is non-obvious to new users.

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 04 Jun '09

04 Jun '09

Caught cancel(cancel) and cancel/abandon(abandon/bind/unbind), partly fixed cancel(cn=config update) problem, without doing this: > Suggested partual fix - add this possible value for o_cancel: > #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Still need something that to fix cancel(cn=config update) completely. syncrepl/syncprov, starttls not yet addressed. Also cancel(cancel) still behaves in a non-RFC way. Correct fix would require resetting o_abandon, which seems unsafe. Who knows what has already reacted to it. Will update this patch for the remaining issues later: > Something like this: > http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt -- Hallvard

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 04 Jun '09

04 Jun '09

Howard Chu wrote: > Andrew Bartlett wrote: >> I agree, we might be jumping at different shadows here, but your patches >> did fix something... > > I see what you're describing now, with the kvm set with 2 CPUs. It appears to > be a bug caused by the recent patch for connection_hangup() processing. > Running slapd with -d15 in your test shows that a connection is closed shortly > after being established and becoming readable. The bug is (probably) that we > queued the reader but processed the hangup immediately, thus closing the > connection before the reader executes. I'm not exactly sure why this is > causing the problem on your test, since it looks like your client is closing > the socket before waiting for the reply. But certainly this is the right area. > With the connection problem out of the way, the remaining slapd crash appeared to be due to some type of heap corruption, but the usual suite of tools (valgrind, efence, LBER_MEMORY_DEBUG, etc.) didn't ever reproduce the problem. On the assumption that this was related to a stack overwrite I recompiled libldap_r with a 12MB stack size instead of the default 8MB and that still didn't change the outcome. On the assumption that there was some other race condition involved, I set slapd to only 2 threads (from default of 16) to try and limit the possibilities there. This caused the crash to occur much more quickly, and using libumem it became obvious that refint was accessing already-freed memory. So it turns out that the patch for rev 1.41 (ITS#5428) to make this into a global overlay was incorrect; it moved the loop that processed its work queue into a new function so that it could be called multiple times, but it was still using that code basically as-is, which freed its queue as it operated. (Because originally the queue was only walked once.) Part of the reason the bug was so hard to reproduce is because it tended to only show up when the queue got fairly long, and that only happened if slapd was too busy. (Thus, forcing only 2 threads made it occur sooner.) -- -- Howard Chu CTO, 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#6152) proxycache enhancements
by mhardin＠symas.com 04 Jun '09

04 Jun '09

On Jun 4, 2009, at 9:15 AM, masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin- > friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many > times it > evaluated to answerable That's very useful. Any thoughts about how to determine pcache's overall 'hit rate'? > > > - "proxycache-" prefixed statements are passed to the private > database. > This allows to avoid ambiguities when applying general database > directives > in slapd.conf. In fact, it is not clear whether they apply to the > proxy > database or to the cache database. Also useful. > > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. I agree. > > > p. > > > -Matt

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 04 Jun '09

04 Jun '09

Just in case, before it becomes totally incompatible with HEAD code, I have a patch I never committed, it's about making pcache admin-friendly if it makes any sense. It adds: - a (persistent) counter that reports, for each query, how many times it evaluated to answerable - "proxycache-" prefixed statements are passed to the private database. This allows to avoid ambiguities when applying general database directives in slapd.conf. In fact, it is not clear whether they apply to the proxy database or to the cache database. If they make sense, I'd like to commit them before slapo-pcache enhancement begins. p.

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 03 Jun '09

03 Jun '09

On a related note, any solution using pcache for disconnected operation should also be able to cache bind operations. This is a digest of a conversation I had with Howard about that: Currently pcache always forwards binds to the db beneath it. These will fail in disconnected cases. One solution is to give the pcache identity read privs to the userpassword, but for security and design reasons that won't fly in most installations. Another solution is to add bind caching to pcache, and that is what is described below. Bind caching functionality can be integrated with pcache, provided that we can meet some conditions: 1. Guarantee that the object being bound against is already in pcache when it passes the bind through. 2. Have an attribute in the cached object where pcache can store a hashed version (e.g. SSHA) of the password it got from the user and verified against the underlying database. Remember that we must verify it against the underlying db before we can write it to cache. Most applications performing LDAP authentication will first search for the object to which they're intending to bind. This will cause condition (1) to be satisfied, but this is not good enough because it is not guaranteed that all applications will first search for the object to which they're binding- some applications build the bind DN 'blindly' using string substitution rules or even hard-coded bind DNs. This is wrong, but it's the way things are. Therefore, pcache itself should search for the object being being bound to and populate the cache with the search result. The details of how the object is added to the cache remain to be determined. Satisfying (1) provides the opportunity to construct an proxyattrset that includes a (possibly dummy) attribute in which the hashed validated password can be stored, thus satisfying condition (2). The userPassword attribute can probably be used most of the time for this, since it will either be returned form the server either empty or with a value of '*'. The "do bind caching directive" might refer to a proxyattrset constructed for this purpose. Bind caching will interact with TTR, but the details are as yet undetermined. To round out the solution, we should also process pwdModify exops as follows: For pwdModify exops, pcache would could operate as a 'write-through' cache, first making sure the object in the cache is current. If the write-through to the underlying database succeeds, then the object in the cache is also updated. Otherwise the exop fails and any cached copy is left unaltered. -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by quanah＠zimbra.com 03 Jun '09

03 Jun '09

--On Wednesday, June 03, 2009 7:22 AM +0000 jonathan(a)phillipoux.net wrote: > Will this patch make it into RE23 for a possible maintenance release of > 2.3? There will be no further releases of OpenLDAP 2.3. You should at this point be working on migrating to the OpenLDAP 2.4 release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 03 Jun '09

03 Jun '09

Suggested partual fix - add this possible value for o_cancel: #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Something like this: http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt Does not reject abandon(Cancel/StartTLS), would need to extend o_cancel with yet another value. That's ugly enough already, so I let that wait. connection_abandon() in particular isn't invalid client action, but it shouldn't be worse than causing a surprising result code or not response before closing the connection. Does not address syncprov's Cancel handler. I don't know if the bconfig.c pathces are correct, but need to reject cancel before (reacting to) thread pool pauses there and maybe in syncrepl/syncprov. -- Hallvard

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 03 Jun '09

03 Jun '09

On 02.06.2009 18:23, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> OK, I've spent some more time trying to understand this part of >> syncprov.c. From what I understand : >> >> - the assert failure in ldap_pvt_runqueue_resched is caused by the fact >> syncprov_qstart is trying to "reschedule" a task that is no longer in >> the task_list >> - the only time the task is removed from the task_list (via >> ldap_pvt_runqueue_remove) is when the task is being run, in >> syncprov_qtask, if syncprov_qplay returns !=0 >> - the next time syncprov_qstart is called, it finds "so->s_qtask" is not >> NULL, and tries to reschedule the task, but it's no longer in the >> task_list. >> >> I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, >> just after removing the task from the task_list. So that when >> syncprov_qstart is called again, it goes into >> ldap_pvt_runqueue_insert... The patch is attached. >> >> Unfortunately, I can't confirm it fixes the bug since I can't reproduce >> it... For those who understand the logic behind this, does this make any >> sense? :) > > Ah, you want rev 1.249 of syncprov.c. Closing this as a dup of ITS#5776. Indeed, that's great. Thanks a lot! > Of course, all of this code has been removed from RE24 as of 1.265. Will this patch make it into RE23 for a possible maintenance release of 2.3? Regards, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

(ITS#6159) olcLimits has no replace/delete
by mbackes＠symas.com 02 Jun '09

02 Jun '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.88.99.93) olcLimits only accepts modify ADD suboperations; replace and delete fail, making any changes to existing olcLimits specifications impossible without stopping and editing LDIF.

1 0

Re: (ITS#6138) Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by h.b.furuseth＠usit.uio.no 02 Jun '09

02 Jun '09

back-ldap:extended.c also does "suppress response, it has been sent", but does it by returning and setting rs->sr_err = SLAPD_ABANDON. Might break assumptions somewhere that SLAPD_ABANDON implies o_abandon was set. And I guess the hack fails if the operation gets cancelled. ======================================================================== I think these are the Operation states related to Cancel and Abandon: op->o_abandon is set for these - could extend to multiple values: A) Operation Abandoned/Cancelled by client. B) Operation implicitly abandoned by client. (Bind or lost connection) C) Operation abandoned by server. (It wants to close the connection) D) Suppress response - a duplicate of the operation will proceed. (syncprov) E) Suppress response - final send_ldap_response() was done. (retcode overlay) rs->sr_err == SLAPD_ABANDON if: F) The backend obeyed o_abandon. (Cancel op, if any, will succeed) G=E) Suppress response - final send_ldap_response() was done. (back-ldap) op->o_cancel packs these states/values: H) The o_abandon is due to a Cancel. I) Cancel operation wants a result, cancelled op must set it and wait. J) Result is available to the Cancel operation. K) Result. (LDAP result code, or SLAP_CANCEL_ACK for success) L) Cancel operation has fetched result, cancelled operation can proceed. States that fit in none of the above, or poorly so: M) Operation must not be waited for, e.g. by Cancel. Operation is itself waiting for others, e.g. cn=config update. N) Operation invisible to Abandon/Cancel/internal abandon. msgID reusable due to result sent to client. Also case D (syncprov)? Fix by removing the op from op->o_conn->c_ops? Or does that just move the problem around? Would need to do something to o_conn to prevent connection_close() from doing connection_destroy(). O) Operation result has been committed, do not abandon. ITS#6059. But o_abandon can be set while trying to commit, unless this flag is set before trying - in which case we can't abandon an operation which is failing to commit, which may be when it's most relevant. Could reset o_abandon, if anyone can keep straight the consequences. Or replace the 'if ( op->o_abandon )' tests with some macro call. Still, interactions with other states could be a problem. About the o_abandon values above: B can be treated like A, I think. C differs in that Cancel/Abandon(operation) should not say "already abandoned" since the client doen't know about the abandon. Could be solved with a vague error message. D-E differ in that o_abandon gets set even though the backends' cancel/abandon handlers were not called. Unsure of the effects of that. D Syncprov duplicating a Persistent Search operation. Handled similar to a server-initiated abandon? Except if the operation cannot be "invisible to Abandon/Cancel" above it must remain possible to Abandon/Cancel it. E Suppress response - response has been sent: Set when exiting slap_send_ldap_result() & co? Handled similar to a server-initiated abandon? At the time slap_send_ldap_result() is called again, the operation may have set up things which need to be cleaned up in the normal way. Yet it has already gone through that function once, doing callbacks etc. Must "final response" code be prepared to be called twice? Beyond that, the main problem would be code which transitions to one state to another, it needs to handle the other cases. -- Hallvard

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 02 Jun '09

02 Jun '09

It might be less intrusive codewise and more flexible if we left the behavior of cache expiration the same and added a parameter to each template called "Time to Refresh" (TTR). Then you set long or unlimited cache expirations, which are always in effect, but set a shorter TTR that would trigger an asynchronous refresh when the TTR expired. If the db is not available these refreshes will simply fail, but the data will remain in the cache at least until it's expired by the usual means. This gives the solution designer the option of deciding how long a system can run disconnected while still being able to separately determine how stale the contents of the cache will get when connected. It also means that pcache itself doesn't need to switch modes based on whether it thinks it's connected to a db or not, and it fact may not need to even know if it is connected or not. There is still room in this design for a flag that controls whether pcache should behave as if it's disconnected or connected, but I'm not sure how useful that is given the changes described above. Cheers, -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by hyc＠symas.com 02 Jun '09

02 Jun '09

jonathan(a)phillipoux.net wrote: > OK, I've spent some more time trying to understand this part of > syncprov.c. From what I understand : > > - the assert failure in ldap_pvt_runqueue_resched is caused by the fact > syncprov_qstart is trying to "reschedule" a task that is no longer in > the task_list > - the only time the task is removed from the task_list (via > ldap_pvt_runqueue_remove) is when the task is being run, in > syncprov_qtask, if syncprov_qplay returns !=0 > - the next time syncprov_qstart is called, it finds "so->s_qtask" is not > NULL, and tries to reschedule the task, but it's no longer in the task_list. > > I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, > just after removing the task from the task_list. So that when > syncprov_qstart is called again, it goes into > ldap_pvt_runqueue_insert... The patch is attached. > > Unfortunately, I can't confirm it fixes the bug since I can't reproduce > it... For those who understand the logic behind this, does this make any > sense? :) Ah, you want rev 1.249 of syncprov.c. Closing this as a dup of ITS#5776. Of course, all of this code has been removed from RE24 as of 1.265. -- -- Howard Chu CTO, 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#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 02 Jun '09

02 Jun '09

This is a multi-part message in MIME format. --------------080204020206070201080405 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.06.2009 12:28, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: 2.3.43 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi, > > I have a 2.3.43 running on a Solaris Sparc server, which crashes occasionally - > once every week or two, always during the night. At this particular time a large > number of operations are performed, including mass deletes and adds. I haven't > been able to reproduce this bug, just watch it happen on the production server > every now and again... > > I managed to obtain a coredump, and a backtrace (at the end of this message). I > realize this isn't much to go on, but I'm rather unfamiliar with this part of > the code, so I wondered if anyone has an idea what's going on here? > > FWIW, the dynlist and chain overlays are in use on the server, and the database > is bdb, with a syncrepl consumer as well as syncprov overlay. > > > Backtrace follows: > 8<------------------------------------------------------------- > Thread 1 (process 1054014 ): > #0 0xfee4aa58 in _lwp_kill () from /lib/libc.so.1 > #1 0xfede5a64 in raise () from /lib/libc.so.1 > #2 0xfedc1954 in abort () from /lib/libc.so.1 > #3 0xfedc1b90 in _assert () from /lib/libc.so.1 > #4 0xff30ef44 in ldap_pvt_runqueue_resched (rq=0x16c630, entry=0xee6c0a0, > defer=0) at rq.c:165 > #5 0xfe7f4a94 in syncprov_qstart (so=0x10acb540) at syncprov.c:933 > #6 0xfe7f4d6c in syncprov_qresp (opc=0x1b1bfaf8, so=0x10acb540, mode=2) at > syncprov.c:982 > #7 0xfe7f5aa4 in syncprov_matchops (op=0xf6bffa50, opc=0x1b1bfaf8, saveit=0) at > syncprov.c:1175 > #8 0xfe7f7490 in syncprov_op_response (op=0xf6bffa50, rs=0xf6bff644) at > syncprov.c:1561 > #9 0x000575cc in ?? () > #10 0x000575cc in ?? () > 8<------------------------------------------------------------- > > Thanks in advance for any pointers! > OK, I've spent some more time trying to understand this part of syncprov.c. From what I understand : - the assert failure in ldap_pvt_runqueue_resched is caused by the fact syncprov_qstart is trying to "reschedule" a task that is no longer in the task_list - the only time the task is removed from the task_list (via ldap_pvt_runqueue_remove) is when the task is being run, in syncprov_qtask, if syncprov_qplay returns !=0 - the next time syncprov_qstart is called, it finds "so->s_qtask" is not NULL, and tries to reschedule the task, but it's no longer in the task_list. I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, just after removing the task from the task_list. So that when syncprov_qstart is called again, it goes into ldap_pvt_runqueue_insert... The patch is attached. Unfortunately, I can't confirm it fixes the bug since I can't reproduce it... For those who understand the logic behind this, does this make any sense? :) Regards, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------080204020206070201080405 Content-Type: text/x-patch; name="patch-syncprov-20090602.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-syncprov-20090602.patch" Index: servers/slapd/overlays/syncprov.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.56.2.51 diff -u -p -r1.56.2.51 syncprov.c --- servers/slapd/overlays/syncprov.c 9 Jul 2008 20:53:13 -0000 1.56.2.51 +++ servers/slapd/overlays/syncprov.c 2 Jun 2009 15:57:21 -0000 @@ -908,6 +908,7 @@ syncprov_qtask( void *ctx, void *arg ) } else { /* bail out on any error */ ldap_pvt_runqueue_remove( &slapd_rq, rtask ); + if ( so ) so->s_qtask = NULL; } ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); --------------080204020206070201080405--

1 0

Re: (ITS#6153) Segfault during Heimdal's kadmin -l init Realm
by hyc＠symas.com 02 Jun '09

02 Jun '09

dewayne_freebsd(a)yahoo.com wrote: > Full_Name: Dewayne Geraghty > Version: 2.4.16 > OS: FreeBSD 7.2R > URL: http://www.consciuminternational.com.au/ldap > Submission from: (NULL) (58.172.112.108) > > > FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 > Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. > Segmentation fault during > kadmin -l > init HS Use Heimdal 1.2.2. https://roundup.it.su.se/jira/browse/HEIMDAL-220 > > slapd and heimdal work correctly, independently. > > slapd is running at debug 1019, logs are at enclosed URL along with the full gdb > trace, and configuration files. If I can assist please advise. > > This is a single Pentium CPU, and gcc flags > CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 > -DDO_SAMBA -DHAVE_OPENSSL > > #0 0x286447b6 in memmove () from /lib/libc.so.7 > #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 > #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 > #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 > #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 > #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 > #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 > #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, > entry=0xbfbfe790) at hdb-ldap.c:1600 > #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, > princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") > at create_s.c:182 > #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, > princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") > at common_glue.c:64 > #10 0x0804e496 in ?? () > #11 0x2871b0c0 in ?? () > #12 0xbfbfea3c in ?? () > #13 0x00000011 in ?? () > #14 0xbfbfe830 in ?? () > #15 0x28084000 in ?? () > #16 0x28084200 in ?? () > #17 0x28084400 in ?? () > #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 > #19 0x0804e8c9 in ?? () > #20 0x2870c0e0 in ?? () > #21 0x00000000 in ?? () > #22 0x00000000 in ?? () > #23 0x00000000 in ?? () > #24 0x2870c085 in ?? () > #25 0x00000000 in ?? () > #26 0x28650030 in ?? () from /lib/libc.so.7 > > I have spent weeks trying to get this to work. (Because I'm using and modifing > the FreeBSD ports system to build and use the latest version of LDAP and > Heimdal.) > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs