Ticket UUID: | 1190441 | |||
Title: | Provide a way to completely disable tclsh history support. | |||
Type: | RFE | Version: | None | |
Submitter: | dossy | Created on: | 2005-04-26 17:23:35 | |
Subsystem: | 19. [history] | Assigned To: | msofer | |
Priority: | 8 | Severity: | ||
Status: | Closed | Last Modified: | 2006-10-01 00:59:43 | |
Resolution: | Fixed | Closed By: | msofer | |
Closed on: | 2006-09-30 17:59:43 | |||
Description: |
In trying to debug memory usage in Tcl, testing from within a tclsh is made difficult by the built-in "history" support. A way to disable it (say, by setting an env var) would be really useful. | |||
User Comments: |
msofer added on 2006-10-01 00:59:43:
File Added - 195999: history.patch Logged In: YES user_id=148712 updated patch, committed. dossy added on 2005-12-01 03:24:29: Logged In: YES user_id=21885 I'm not talking about a memory leak -- yes, we might have those, too -- I'm talking about a "resource abuse leak" -- where one thread running some Tcl script is using/holding on to a sizable amount of memory and not cleaning up after itself. Currently, there's very little that I know of for debugging this stuff. I can use the seemingly unsupported Tcl_GetMemoryInfo() but that's not fine-grained enough to solve my problem. So, I log each thread's creation and every time a thread allocs/frees memory, then do point-in-time "accounting" figuring out net memory-in-use per thread and try to graph it over time to see which thread is using memory and tie it back to what Tcl script it might have been executing at the time. I'm thinking about hijacking Tcl_NewObj() and friends to track Tcl_Obj creation/destruction, but that's going to be a lot of work (but probably *exactly* what I need, here). hobbs added on 2005-12-01 03:19:29: Logged In: YES user_id=72656 Unless you suspect the threaded Tcl allocator itself, all mem debugging should be done with -DPURIFY enabled, and exit the process by first renaming exit to {}. The latter may not be necessary if you are using Tcl embedded and properly delete the final interp and finalize. dossy added on 2005-12-01 03:16:18: Logged In: YES user_id=21885 I have a (dirty hack) LD_PRELOAD library that uses dlsym() trickery to wrap Tcl_Alloc, Tcl_Realloc and Tcl_Free with my own versions that do some logging (then calls the saved pointers to the original functions). Apparently there's a bunch of hooey that goes on in the Tcl_EvalObjEx() machinery and having two such calls, instead of one, adds a lot of "noise" to the logging. I'm struggling with trying to track down where memory is actually being used in multi-threaded Tcl -- AOLserver. I try to test some things from a normal (interactive) tclsh to compare its logs to what's going on in AOLserver, but it's confusing. I also hijack a bunch of AOLserver "Ns_*" symbols as well. It's all very exciting, but hasn't revealed much yet. hobbs added on 2005-12-01 02:46:17: Logged In: YES user_id=72656 Miguel - that sounds good, although I'm dubious why this should really make memory debugging any harder (since I've been doing mem debugging lately, and 'proc history args {}' sufficed). msofer added on 2005-11-30 09:37:32: File Added - 158067: history.patch msofer added on 2005-11-30 09:37:31: Logged In: YES user_id=148712 Even easier: Tcl_RecordAndEvalObj could check if [history] is a proc with empty body, in which case it would skip calling it. This is a very simple change (patch attached untested!), waiting for comments before commiting: acceptable? satisfies dossy's needs? dossy added on 2005-11-30 07:55:32: Logged In: YES user_id=21885 That doesn't stop the constant Tcl_Eval'ing of the "history" commands, though. That adds a bunch of noise to the debugging process. I think the answer might be to create a LD_PRELOAD hack that hijacks the Tcl_RecordAndEvalObj() function using dlsym() hacks, since Tcl_Main() calls it. My point was, it'd be nice if there were a way to tell Tcl_Main() to just call Tcl_EvalObjEx() directly -- or, tell Tcl_RecordAndEvalObj() to not eval the "history add <foo>". Thanks. hobbs added on 2005-11-30 04:55:35: Logged In: YES user_id=72656 just add 'proc history args {}' at the beginning of a script to disable it. |
Attachments:
- history.patch [download] added by msofer on 2006-10-01 00:59:43. [details]