libprldap "cross thread" memory leak

RESOLVED FIXED in 5.11

Status

P1
normal
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: mcs, Assigned: mcs)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
If a different thread calls ldap_unbind() than created or used an LDAP session,
the thread-private error information stored by the prldap layer is leaked.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 5.11
(Assignee)

Comment 1

16 years ago
Created attachment 106101 [details] [diff] [review]
proposed fix

There were actually two problems:

1) The prldap_tsd_destroy() function (which is called when a thread exits) was
not freeing the information contained within the PRLDAP_ErrorInfo structure. I
added a prldap_free_errorinfo() and a way to determine if that thread-private
data looks like error information (the plei_magic field). Right now, we only
store one kind of thread-private data anyway.

2) The prldap_allocate_map() function, which is called when a new LDAP session
is created, was blindly setting the thread-private error information pointer to
NULL. But if a different thread created or used an LDAP session than called
ldap_unbind(), old error information may still be present in memory. Now we
reset it and reuse it, which was my original intent when I wrote the prldap
code.
(Assignee)

Updated

16 years ago
Attachment #106101 - Flags: review?(mcs)
(Assignee)

Updated

16 years ago
Attachment #106101 - Flags: review?(mcs) → review?(richm)

Comment 2

16 years ago
Fix looks good.
(Assignee)

Comment 3

16 years ago
Fixed on the trunk:

mozilla/directory/c-sdk/ldap/libraries/libprldap/ldappr-threads.c
  new revision: 5.2; previous revision: 5.1
    Fix bug # 179951 - libprldap "cross thread" memory leak.
        The prldap_tsd_destroy() function (which is called when a
        the PRLDAP_ErrorInfo structure. Added prldap_free_errorinfo()
        and a way to determine if that thread-private data looks like
        error information (the plei_magic field). At the moment, only
        one kind of thread-private data is stored anyway (the error
        information).

        The prldap_allocate_map() function, which is called when a new
        LDAP session is created, was blindly setting the thread-private
        error information pointer to NULL. But if a different thread
        created or used an LDAP session than called ldap_unbind(), old
        error information may have been left in memory. Now the error
        info. pointer is reset and reused, which was the original goal.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Attachment #106101 - Flags: review?(richm)

Comment 4

16 years ago
Spam for bug 129472
QA Contact: nobody → nobody
You need to log in before you can comment on or make changes to this bug.