This was meant to be followup to ITS#76.  Due to extra space after the
# sign, the system failed to recognize it as such.

Regrettably, -bug readers will have to put up with forwarding.

	Kurt

At 10:05 PM 2/18/99 GMT, dirk-n@dircon.co.uk wrote:
>I have found out more about the coredump- 
>I can reproduce it using 'ldapsearch' using the following command line 
>(with my ldif file)
>
>ldapsearch -v -D
>'cn=WWW/LDAP-Gateway,cn=fornax,ou=IT,ou=Admin,ou=Periphonics VPS
>Ltd.,c=GB,ou=Periphonics EMEA,o=Periphonics Corporation,dc=peri,dc=com'
>-b 'c=GB,ou=Periphonics EMEA,o=Periphonics Corporation,dc=peri,dc=com'
>-s base -a find  'objectclass=*'
>
>It's caused when:
>a) base DN is set to a value like
>'ou=MyOrgU,ou=MyHigherOrgU,o=MyOrg,c=GB'
>b) we are beginning a search with filter 'objectclass=*'
>c) the DN we begin the search with is something like
>'ou=MyHigherOrgU,o=MyOrg,c=GB'
>  (so it's above the base. does this even make sense)
>d) There is no DN entry in the database for
>'ou=MyHigherOrgU,o=MyOrg,c=GB'
>   but there is one for 'o=MyOrg,c=GB'
>e) alias deref is set to always or search. i.e we have to try aliases on
>this. 
>
>There is a problem in derefDN in back-ldbm/alias.c where it is possible
>that we break out of the first large alias search loop with newDN set to
>NULL.
>The second loop (which checks to see if there are any aliases left in
>the remaining part of the DN, I guess) could call dn2entry_r with a NULL
>DN. That's what causes the segfault.. 
>
>I've got a fix that will stop the coredump, but I think it might break
>the alias mechanism in more general ways. Basically consists of an
>if(NewDN != NULL) wrapper around the second alias search loop. If newDN
>is set to null the derefDN routine then just returns the old DN. I have
>no idea whether that behaviour is correct.
> 
>here is a diff (I don't think it actually fixes behaviour, it just
>prevents 
>the coredump.
>----------------------------------- cut here
>-----------------------------------
>--- alias.c.orig        Thu Feb  4 18:49:52 1999
>+++ alias.c     Thu Feb 18 21:29:48 1999
>@@ -278,15 +278,17 @@
>    * e.g. if we had started with dn = o=MyAliasedOrg,c=MyCountry the dn
>would match
>    * and the above loop complete but we would still be left with an
>aliased DN.
>    */
>-  if ( (eNew = dn2entry_r( be, newDN, &matched )) != NULL) {
>-    if ((eDeref = derefAlias_r( be, conn, op, eNew )) != NULL) {
>-      free (newDN);
>-      newDN = ch_strdup (eDeref->e_dn);
>+  if (newDN != NULL) {
>+    if ( (eNew = dn2entry_r( be, newDN, &matched )) != NULL) {
>+      if ((eDeref = derefAlias_r( be, conn, op, eNew )) != NULL) {
>+        free (newDN);
>+        newDN = ch_strdup (eDeref->e_dn);
>+        /* free reader lock */
>+        cache_return_entry_r(&li->li_cache, eDeref);
>+      }  
>       /* free reader lock */
>-      cache_return_entry_r(&li->li_cache, eDeref);
>+      cache_return_entry_r(&li->li_cache, eNew);
>     }
>-    /* free reader lock */
>-    cache_return_entry_r(&li->li_cache, eNew);
>   }
>   if (matched != NULL) free(matched);
>   
>------------------------------ cut here -------------------------------
> |  /  _ \ _ _| __ \          Dirk Niggemann 
> ' /  |   |  |  |   |         dirk-n@dircon.co.uk 
> . \  __ <   |  |   |         
>_|\_\_| \_\___|____/
>
>

dirk-n@dircon.co.uk writes:

> There is a problem in derefDN in back-ldbm/alias.c (...)

I suggest set SLAPD_DEFAULT_MAXDEREFDEPTH to 0 in ldapconfig.h.edit
until somone finds time to clean up the alias code, and apply this patch
to back-*/search.c:

*** search.c~	Thu Feb 11 18:19:52 1999
--- search.c	Sat Feb 20 11:14:35 1999
***************
*** 77,80 ****
--- 77,83 ----
  	 */
  
+ 	if ( be->be_maxDerefDepth <= 0 )
+ 		deref = LDAP_DEREF_NEVER;
+ 
  	switch ( deref ) {
  	case LDAP_DEREF_FINDING:

-- 
Hallvard

moved from Incoming to Software Bugs

changed state Open to Release

changed notes

changed notes

changed state Release to Closed

Fixed in 1.2.1