[email protected] wrote: > [email protected] wrote: >> Hi >> >> Here's some information that Stephen asked would be of use. There is >> one forest, one domain, but three sites in the layout. The functional >> level of the forest and the domain is W2008, but the servers have 2008R2. >> >> And the full backtrace of the hung process: > >> #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock >> (mutex=0x7f8f6553fc80) >> at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 >> No locals. >> #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, >> dn=0x0, >> mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, >> flags=2, >> interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at >> sasl.c:426 >> rc = -1921681294 >> smechs = 0x0 > > This particular mutex seems kind of bogus to me; the code is from rev 1.31 in > June 2001. Perhaps back then it was unsafe to have multiple SASL operations > outstanding at once; I would expect that was only an issue in the Cyrus 1.5 > days and it should be safe now with Cyrus 2.x. We should probably just delete > this mutex. > Although googling for "Cyrus sasl reentrancy" does not leave me with warm/fuzzy feelings.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
