| Ticket UUID: | 3384840 | |||
| Title: | assemble.test leaks | |||
| Type: | Bug | Version: | obsolete: 8.6b2 | |
| Submitter: | msofer | Created on: | 2011-08-02 16:26:32 | |
| Subsystem: | 47. Bytecode Compiler | Assigned To: | dkf | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2011-08-07 04:21:17 | |
| Resolution: | Fixed | Closed By: | kennykb | |
| Closed on: | 2011-08-06 20:53:22 | |||
| Description: |
Running assemble.test under valgrind shows very many leaks - 107 different stack traces of depth 10. Attaching the full valgrind output and a summary of leaks, grouped by identical stack traces. | |||
| User Comments: |
msofer added on 2011-08-07 04:21:17:
I don't see any more leaks in assemble.test ... kennykb added on 2011-08-07 03:53:22: And it's also necessary to clean up all the bits and pieces that TIP 280 leaves behind I think that's the last one from miguel's list. kennykb added on 2011-08-07 02:55:29: Hah. When you're abandoning a CompileEnv because of a compile-time error, you have to clean up its literal pool and auxdata manually. Who knew? Still a few leaks left, leaving the bug open. kennykb added on 2011-08-06 23:36:01: Plugged another leak. The one that's puzzling me now is that there is a cascade of leaks appearing from the test cases 'assemble-30.[45]' (at least). It appears to be leaking a registered literal. Refcount imbalance on error exit from the assembler? msofer added on 2011-08-04 21:26:28: good job, 24 more to go :) msofer added on 2011-08-04 21:25:56: File Added - 420275: res.leaks dkf added on 2011-08-04 21:14:40: That should be a bunch more; definitely not cleared all of them though, as some are coupled in ways I don't yet grok. msofer added on 2011-08-04 20:41:24: File Added - 420269: res.leaks msofer added on 2011-08-04 20:40:58: File Added - 420268: res msofer added on 2011-08-04 20:40:13: allow_comments - 0 Ouch, still 41 leaks to go :( Attaching new reports in a minute msofer added on 2011-08-04 20:20:35: Fix confirmed, thx dkf added on 2011-08-04 20:18:16: allow_comments - 1 Was due to GetNextOperand doing Tcl_Obj allocation yet some callers of it already holding a reference to a Tcl_Obj in the out parameter. Oops! Please recheck, but I think that's the issue squelched. msofer added on 2011-08-02 23:27:48: File Added - 420071: res.leaks msofer added on 2011-08-02 23:26:33: File Added - 420070: res | |||
Home
Timeline
Branches
Tags
Tickets
Download
Wiki