| Summary: | Enabling threads leads to memory-leak | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Jeremy Sowden <jeremy> | ||||
| Component: | tdom | Assignee: | Orphan Owner <extras-orphan> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | el6 | CC: | extras-orphan | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-11-30 14:59:16 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Created attachment 798251 [details]
Proposed patch
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) 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. 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. |
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.