|
2023-04-15
| ||
| 21:28 | • Closed ticket [6d4e9d1af5]: memory leak: SetFsPathFromAny, assisted by the global literal table, causes a Tcl_Obj to reference itself plus 4 other changes artifact: 6c163527d5 user: pooryorick | |
|
2023-03-30
| ||
| 19:01 | • Ticket [578155d5a1] Very rare bug (segfault) if set variable (with error case) using self-releasable object as new value status still Pending with 3 other changes artifact: 3228d41af0 user: pooryorick | |
|
2023-03-28
| ||
| 16:30 | Merge trunk [7d005e0860]: Fix for [6d4e9d1af5bf5b7d]: Memory leak: SetFsPathFromAny, assisted by th... check-in: 48d19d4cc3 user: pooryorick tags: unchained | |
|
2023-03-26
| ||
| 15:35 | Fix for [6d4e9d1af5bf5b7d]: Memory leak: SetFsPathFromAny, assisted by the global literal table, ca... check-in: 7d005e0860 user: pooryorick tags: trunk, main | |
| 15:10 | • Pending ticket [6d4e9d1af5]: memory leak: SetFsPathFromAny, assisted by the global literal table, causes a Tcl_Obj to reference itself plus 4 other changes artifact: dab9b2e1cc user: pooryorick | |
| 15:08 | • Ticket [6d4e9d1af5]: 3 changes artifact: 55234a87f2 user: pooryorick | |
| 15:07 | Fix for [6d4e9d1af5bf5b7d]: Memory leak: SetFsPathFromAny, assisted by the global literal table, ca... check-in: a9c542391a user: pooryorick tags: core-8-branch | |
| 15:02 | Fix for [6d4e9d1af5bf5b7d]: Memory leak: SetFsPathFromAny, assisted by the global literal table, ca... Closed-Leaf check-in: fb9a2adbd2 user: pooryorick tags: bug-6d4e9d1af5bf5b7d | |
| 14:55 | Failing test for [6d4e9d1af5bf5b7d]. check-in: 8f233171f2 user: pooryorick tags: bug-6d4e9d1af5bf5b7d | |
| 10:30 | • Ticket [6d4e9d1af5] memory leak: SetFsPathFromAny, assisted by the global literal table, causes a Tcl_Obj to reference itself status still Open with 3 other changes artifact: b66403dab9 user: pooryorick | |
| 10:30 | • New ticket [6d4e9d1af5]. artifact: fe01f173f4 user: pooryorick | |
| Ticket UUID: | 6d4e9d1af5bf5b7dc8c359c2c169974c0b963066 | |||
| Title: | memory leak: SetFsPathFromAny, assisted by the global literal table, causes a Tcl_Obj to reference itself | |||
| Type: | Bug | Version: | ||
| Submitter: | pooryorick | Created on: | 2023-03-26 10:30:33 | |
| Subsystem: | 36. Pathname Management | Assigned To: | pooryorick | |
| Priority: | 5 Medium | Severity: | Critical | |
| Status: | Closed | Last Modified: | 2023-04-15 21:28:55 | |
| Resolution: | Fixed | Closed By: | pooryorick | |
| Closed on: | 2023-04-15 21:28:55 | |||
| Description: |
SetFsPathFromAny duplicates a Tcl_Obj and then stores a pointer to the new object in a fsPathPtr, which it then sets as the internal representation of another Tcl_Obj, pathPtr. Because no care is taken to ensure that the internal representation of the newly-duplicated Tcl_Obj contains no reference-counted copy of pathPtr, it's possible for a situation to arise where pathPtr contains a pointer to itself, and that its reference count therefore never drops to 0, which is a memory leak. In test Tcl_Main-2.1 such a situation does in fact occur: "result" is a literal value that, by the time SetFsPathFromAny receives it, has already been entered into the literalTable of the interpreter, and has also received an internal representation of type "localVarNameType", possibly due to its appearance in procedures within msgcat.tcl. When pathPtr is duplicated, DupLocalVarName() makes pathPtr the internal representation of the duplicated object, transPtr. Then transPtr is stored in fsPathPtr, which becomtes the internal representation of pathPtr. Valgrind reports still-reachable blocks due to this situation, but only when all other tests are deleted from the source file. Although this issue can be fixed by modifying SetFsPathFromAny, it is yet another example of how sharing a single Tcl_Obj between identical literal values causes trouble. First, it creates a situation where there is only one internal representation even though the identical literal values may have different contexts and interpretations. Second, it makes errors like this one, which can go undiscovered for years, more likely. | |||
| User Comments: |
pooryorick added on 2023-03-26 15:10:33:
Correction: Fixed in [a9c542391a86a9e8]. pooryorick added on 2023-03-26 15:08:55: Fixed in [1ec9da4c469c29f4]. | |||