I am using perlldap 1.0 (and ldap SDK 3.0) on Windows NT. Most of the time everything is fine, but I experience trouble searching for an NON-EXISTING DN. When I try the following: $conn = new Mozilla::LDAP::Conn($LDAP_SERVER, $PORT, $ROOTDN, $ROOTPW); $e1 = $conn->search ($BASEDN, "subtree", "ldap:///$existingDN"); $e2 = $conn->search ($BASEDN, "subtree", "ldap:///$nonExistingDN"); $e3 = $conn->search ($BASEDN, "subtree", "ldap:///$anyDN"); the program, i.e. perl (!) crashes (Dr. Watson). Since the first (existing) DN is found and I can work with it (printLDIF etc.), I don't think the connection or the search is wrong. When I leave out the first search (for the existing DN) nothing unusual happens (the non-existing DN is not found, that's all). And when I leave out the last search (for existing or non-existing DN), everything is fine. Any ideas to get rid of this ? or work around ? Or will this be fixed in the long awaited perlLDAP v1.1 ? thanks, gerhard -- Gerhard Weber: ACTIV-CONSULT Multimedia und Training GmbH Online Service Center Nordhauser Str. 30 10589 Berlin Tel.: + 49/30/3 46 02-2 35 mailto:gerhard@activ-consult.de http://www.activ-consult.de

I'm not 100% sure, but I suspect this is because there is no filter in the URL. The proper syntax when doing this search ought to be something like ldap:///$anyDN???(objectclass=*)

I've been able to reproduce a crash on Solaris when searching in a BASEDN that does not exist (bus error, OS says "Bad free()"). I've spoken with the DS folks a little about this and hope to find out more. The only work around I am aware of is to test down the tree from a node you are certain exists. If you encounter a missing node before you get to your entry, do not continue down the tree.

Setting all current Open Critical and Major to M3

Clearing "M" field since Directory product is not used for 5.0 specific project bug metrics and will mess up our queries on milestones.

This bug may have been fixed between Conn.pm 1.18 and Conn.pm 1.19 The specific fix was in search() ldap_msgfree($self->("ldres")) if defined($self->("ldres")); was changed to: if (defined($self->{"ldres"})) { ldap_msgfree($self->{"ldres"}}; undef $self->{"ldres"}; } The bug is that if you have a search with results, followed by a search with no results, the search with no results calls ldap_msgfree, but doesn't overwrite or undef the ldres. When the third search is performed, it calls ldap_msgfree on the same ldres a second time, which causes crashes or other problems. I'll send an email to the user to see if they still have the problem. I can't speak to kburns comments on 1/20 but I don't think that's the same problem that Gerhard is reporting.

Gerhard writes back: Hi Kevin Sorry for replying so late - but i was so busy doing lot of boring things...u know how it is I am no longer working on the project where this bug occured. Leif told me a workaround so i just i forgot about this bug. i don't think i will find enough time to check again with the latest perl LDAP version within the next two weeks or so - sorry bout this - especially when i think of how fast you guys helped me out. so promised - when i get the time, i will check if the problem still exists with the new version. bye and eveverything gerhard

Fixed.

Fixed.

<spam> This bug is 1337 ;-) </spam>