| Ticket UUID: | 7e3f26c7481986b6c90359fd24d713a5c96c55f9 | ||
| Title: | Memory corruption false positive with TCL_MEM_DEBUG | ||
| Type: | Bug | Created on: | 2023-04-02 12:04:27 |
| Submitter: | apnadkarni | Assigned to: | nobody |
| Subsystem: | - New Builtin Commands | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2026-10-18 10:03:22 |
| Status: | Open | Closed by: | nobody |
| Resolution: | None | Closed on: | |
| Version: | 9.0.5, 9.1.0 | ||
| Description: | ||||
|
Tcl built with Encountered while testing lrepeat | ||||
| User Comments: | ||||
apnadkarni added on 2023-04-02 12:13:04:
Note on 8.x and 32-bit 9.0 this particular test case does not succeed as lists of that size are not permitted ``` % llength [lrepeat 0x61616162 x] max length of a Tcl list (536870906 elements) exceeded ``` apnadkarni added on 2023-04-02 13:26:30:
Fixed for 9.0 in [f505b17748]. Leaving open for time being to see if it can be reproduced in 8.x or 32-bit Tcl. If so, the 0x61616161 pattern may have to change one with high bit set. fvogel added on 2023-04-02 17:37:29:
In addition to [f505b17748] the codebase features 4 more occurrences of the same 0x61616161 special value, one in tclDisassemble and three in tclPreserve. Shouldn't these be considered to be renamed FREEDREFCOUNTFILLER? apnadkarni added on 2023-04-03 02:09:32:
You're right. Also, rethinking the 32-bit case, perhaps the issue could arise there as well for other object types. Maybe the 61 marker should be changed to something like E8 (high bit set, printable) to reduce the chances of this occurring in 32-bit systems (6161616161616161 is basically impossible in 64-bit systems (unless one artificially keeps incrementing for no reason) but 61616161 may be feasible on 32-bits with valid references. I'll wait in case someone else has comments/ideas to fix both these. Keeping ticket open for now. serhiy.storchaka added on 2026-10-18 10:03:22:
[f505b17748] changed the expected refCount of freed objects to 0xE8..., but Tcl_DbCkfree still fills freed memory with 0x61, so the "decrementing refCount of previously disposed object" panic can no longer fire; a use-after-free decrement is caught only by the threaded check ("Tcl_Obj allocated in another thread", without file and line). The 0x61616161 checks in tclDisassemble.c and tclPreserve.c never matched on 64-bit either. Proposed fix in branch memdebug-freed-marker: Tcl_DbCkfree fills freed memory with 0xE8, as suggested here, and all five checks use the same marker. A use-after-free decrement now panics with the file and line again. | ||||