Bug 1008457 - Enabling threads leads to memory-leak
Summary: Enabling threads leads to memory-leak
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: tdom
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-16 11:47 UTC by Jeremy Sowden
Modified: 2020-11-30 14:59 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-30 14:59:16 UTC
Type: Bug


Attachments (Terms of Use)
Proposed patch (5.01 KB, patch)
2013-09-16 11:48 UTC, Jeremy Sowden
no flags Details | Diff

Description Jeremy Sowden 2013-09-16 11:47:28 UTC
Description of problem:

  There's a bug in 0.8.2 when thread support is enabled that leads to memory-leaks.  The function tcldom_returnDocumentObj which is used to return references to the DOM document object increments the reference-count for the object; in most cases this is the correct thing to do; either the object is new and the ref. count becomes one, or it is being shared between threads.  However, tcldom_returnDocumentObj is also called by [domNode ownerDocument], in which case there is no new reference.  In this case, when the document is later deleted the ref. count is incorrect and the document is not properly freed.

  It is fixed upstream in this commit:

    https://github.com/tDOM/tdom/commit/2cc0f54af0d110acaabed5c1625eb35ac213f9eb

Version-Release number of selected component (if applicable): 0.8.2

How reproducible:

  Run the following Tcl script under valgrind:

    set i [interp create]

    interp eval $i {

      package require tdom

      for { set i 0 } { $i < 1024 } { incr i } {

	set doc [dom createDocument doc]

	set elem [$doc documentElement $doc]

	[$elem ownerDocument] delete

      }

    }

    interp delete $i

  It includes a number of possibly lost allocations such as the following:

    3,952 bytes in 988 blocks are possibly lost in loss record 22 of 85
       at 0x4C2935B: malloc (vg_replace_malloc.c:270)
       by 0x5942D11: strdup (strdup.c:42)
       by 0x72DD0A7: domNewNamespace (dom.c:818)
       by 0x72E03C9: domCreateXMLNamespaceNode (dom.c:2229)
       by 0x72E0675: domCreateDoc (dom.c:2313)
       by 0x72E087A: domCreateDocument (dom.c:2374)
       by 0x732F198: tcldom_createDocument (tcldom.c:5194)
       by 0x73309A6: tcldom_DomObjCmd (tcldom.c:5727)
       by 0x4E6BE24: TclEvalObjvInternal (tclBasic.c:3693)
       by 0x4ED21A1: TclExecuteByteCode (tclExecute.c:2416)
       by 0x4ED035C: TclCompEvalObj (tclExecute.c:1537)
       by 0x4E6E3BA: TclEvalObjEx (tclBasic.c:5260)

  These possible losses is not present if one runs the script without calling ownerDocument:

    set i [interp create]

    interp eval $i {

      package require tdom

      for { set i 0 } { $i < 1024 } { incr i } {

	set doc [dom createDocument doc]

	set elem [$doc documentElement $doc]

	$doc delete

      }

    }

    interp delete $i

  or with a patched build of tDOM.

  I have attached a patch generated against the RPM sources.

Comment 1 Jeremy Sowden 2013-09-16 11:48:20 UTC
Created attachment 798251 [details]
Proposed patch

Comment 2 Jeremy Sowden 2013-09-17 09:42:05 UTC
The above possible losses are from tests against the wrong installation of Tcl.  Running the test against the correct (single-threaded) el6 Tcl, there's a definite leak:

==26182== 958,464 (327,680 direct, 630,784 indirect) bytes in 1,024 blocks are definitely lost in loss record 356 of 356
==26182==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==26182==    by 0x6CBF449: domCreateDoc (dom.c:2272)
==26182==    by 0x6CBF87A: domCreateDocument (dom.c:2374)
==26182==    by 0x6D0E198: tcldom_createDocument (tcldom.c:5194)
==26182==    by 0x6D0F9A6: tcldom_DomObjCmd (tcldom.c:5727)
==26182==    by 0x4E6B373: TclEvalObjvInternal (tclBasic.c:3693)
==26182==    by 0x4ED2941: TclExecuteByteCode (tclExecute.c:2416)
==26182==    by 0x4ED09E0: TclCompEvalObj (tclExecute.c:1537)
==26182==    by 0x4E6D956: TclEvalObjEx (tclBasic.c:5260)
==26182==    by 0x4EECA3F: SlaveEval (tclInterp.c:2611)
==26182==    by 0x4EE9796: Tcl_InterpObjCmd (tclInterp.c:789)
==26182==    by 0x4E6B373: TclEvalObjvInternal (tclBasic.c:3693)

Comment 3 Ben Cotton 2020-11-05 16:49:08 UTC
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged  change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.

Comment 4 Ben Cotton 2020-11-30 14:59:16 UTC
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
EPEL please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.