Closed
Bug 1337
Opened 26 years ago
Closed 26 years ago
Dr Watson during certain searches/browsing of a DN
Categories
(Directory :: PerLDAP, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: leif, Assigned: leif)
Details
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
Assignee | ||
Updated•26 years ago
|
Severity: normal → major
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•26 years ago
|
||
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=*)
Assignee | ||
Updated•26 years ago
|
Priority: P2 → P3
Comment 2•26 years ago
|
||
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.
Clearing "M" field since Directory product is not used for 5.0 specific project
bug metrics and will mess up our queries on milestones.
Comment 5•26 years ago
|
||
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.
Comment 6•26 years ago
|
||
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
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•26 years ago
|
||
Fixed.
Assignee | ||
Comment 8•26 years ago
|
||
Fixed.
Comment 9•22 years ago
|
||
<spam> This bug is 1337 ;-) </spam>
You need to log in
before you can comment on or make changes to this bug.
Description
•