Closed
Bug 10431
Opened 25 years ago
Closed 25 years ago
Core dump performing update
Categories
(Directory :: 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•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P1
Assignee | ||
Comment 1•25 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•25 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•25 years ago
|
||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 4•25 years ago
|
||
Fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•