Description of problem: I'm building 389 (branch 1.2 from git) for ALT Linux. Build if ok, but server fails after first search: [26/Aug/2009:20:57:37 +0400] 389-Directory/1.2.2 - debug level: packets+connections (10) [26/Aug/2009:20:57:38 +0400] - 389-Directory/1.2.2 B2009.238.956 starting up [26/Aug/2009:20:57:38 +0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [26/Aug/2009:20:57:40 +0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/Aug/2009:20:57:56 +0400] - sasl_io_cleanup for connection 0 Assertion failure: 0 != id, at prlayer.c:579 Aborted Version-Release number of selected component (if applicable): 1.2 branch (commit 30e3822919e20cb13dfc5dabc50e7c1fe5e21d40 from git) Steps to Reproduce: 1. start ns-slapd 2. query something Actual results: server fails ;( Expected results: server not fails and return something
Are you using a build of NSPR with PR_ASSERT enabled?
(I'm not good with nspr) Yes, we build nspr-4.8.0 with -DDEBUG=1 (As I see equal to -DFORCE_PR_ASSERT=1)
Ok. The problem is that we pop the SASL IO layer even if there is no SASL IO layer. There is no bad effect. The fix will be to check to see if SASL IO has been enabled, and if the layer contains the SASL IO layer. This targeted for the next bug fix release.
Thanks, I'll trace git commits ;)
Created attachment 362292 [details] Simple patch to fix problem (check for c_prfd in connection before calling sasl_io_cleanup)
Created attachment 362324 [details] revised patch
To ssh://git.fedorahosted.org/git/389/ds.git 56b9868..7f9f261 master -> master commit 7f9f26112388c6915fafb1b60b41a2d3e1e4e51e Author: Rich Megginson <rmeggins> Date: Wed Sep 23 09:52:29 2009 -0600 Reviewed by: nkinder (Thanks!) Fix Description: Before attempting to pop the SASL IO layer from the prfd, first make sure we are using sasl IO, the prfd is not NULL, and the prfd has a SASL IO layer on it. This also fixes a bug with setting nsslapd-localhost in the bootstrap code - if you are using a system that does not have DNS configured correctly, you may want to force the SASL code to use the nsslapd-localhost for the FQDN. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no
verified - SASL nightly acceptance tests passing - all supported platforms