Closed
Bug 10431
Opened 26 years ago
Closed 26 years ago
Core dump performing update
Categories
(Directory Graveyard :: PerLDAP, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kmccarth, Assigned: kmccarth)
Details
Attachments
(1 file)
|
3.61 KB,
patch
|
Details | Diff | Splinter Review |
From Anthony.Wood@pacificpower.com.au:
Hey Leif,
cool modules. Here's a core-dumping bug for you.
I know I'm meant to post this to the newsgroup, but I can't access non
usenet news through our firewall.
If you're no longer in this gig, please do a short reply, and I'll hassle
someone else.
Work-around is do an update between the addValue and removeValue.
(perl 5.005_02; solaris 2.6 on an Ultra 2).
here's the program:
use Mozilla::LDAP::Conn;
my $conn = new Mozilla::LDAP::Conn(ldap,389,"cn=Directory
Manager","password");
my $entry = $conn->search("o=company",
"subtree","(uid=woody)",0,("uid","cn"));
$entry->addValue("cn","testing123");
$conn->update($entry);
$entry->addValue("cn","testing456");
$entry->removeValue("cn","testing123");
$conn->update($entry);
# program doesn't get to here. Entry is actually updated, though.
# if you comment out the offending update, the program doesn't crash, as the
remove undoes the add
$entry->removeValue("cn","testing456");
$conn->update($entry);
$conn->close();
regards,
Anthony Wood
__________________________________________________________________________
\ / |Anthony Wood - Web Team, Facilities Branch, Information Systems
\/\/ OODY|Group, Pacific Power Commercial: +61 2 9268 6572 fax: 9268 6144
| Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P1
| Assignee | ||
Comment 1•26 years ago
|
||
Hi Kevin,
want to take a look at this? He's using PerLDAP v1.2.2 (I asked him).
-- Leif
| Assignee | ||
Comment 2•26 years ago
|
||
I have found two memory problems inside API.xs that I believe are responsible
for the problem (and maybe even for some of the NT problems):
1. The ldap_current_attribute string was being assigned into multiple
LDAPMod->mod_type elements when more than change was made for the
same attribute (which is happening in the sample script)
This causes the ldap_current_attribute to be free'dd multiple times by
ldap_mods_free().
2. Inside hash2mod, it was allocating too few LDAPMod** entries: it
was calculating the number of attributes that were being changed.
An attribute can be both added "ab" and deleted "db" from at the
same time, so this is just plain wrong. Major memory corruptor...
I will post a patch file shortly, and email the patch file to Anthony to test.
-Kevin
| Assignee | ||
Comment 3•26 years ago
|
||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 4•26 years ago
|
||
Fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•