Tcl Source Code

View Ticket
Login
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: