Tcl Source Code

The crash happens on Windows 2000 (SP2):

simple script:
tclsh
% rename info ::tcl::info
% foo
Crash.

I see this crash with the following versions:
8.3.2 (TclPro 1.4.1)
8.3.4 (ActiveState/own Build)
8.4.0 (ActiveState/own Build)
8.4.2 (ActiveState/own Build)
8.5a0 (nearly CVS HEAD)

I also see the crash with a threaded tclsh 8.4.2.

I'll append the stack trace for 8.5a0 (no other debug
build available)

The bug dissapears if one calls:
% interp recursionlimit {} 50
% rename info ::tcl::info
% foo
too many nested evaluations (infinity loop?)

running:
proc recurse {int} {
     puts $int
     recurse [incr int]
} 
% recurse 0
gives 428 as last value before the stack limit is reached.

Logged In: YES 
user_id=148712

So: the bug is actually "too small a value of
TCL_WIN_STACK_THRESHOLD"?

Logged In: YES 
user_id=148712

The call to TclInterpReady is now part of
TclEvalObjvInternal - this is a fix for the new incarnation
of [Bug 495830] in 8.4. This resolves the issue that some
paths to TEOVI were missing the TIR call raised  in a
previous comment.

Logged In: YES 
user_id=113501

Increasing the TCL_WIN_STACK_THRESHOLD define to 0x8000 
seems to fix the bug here (Windows NT 4.0).

Logged In: YES 
user_id=113501

I'm able to reproduce this now on Windows NT 4.0.

This appears to be caused by code paths that do not hit 
Tcl_InterpReady in TclEvalObjvInternal. In addition, there is 
no Tcl_InterpReady check in TclObjInterpProc or 
TclExecuteByteCode. However, I don't actually think the 
check should be needed in TclExecuteByteCode as long as we 
have the other two.

Logged In: YES 
user_id=113501

The stack overflow core dumps are fixed on several versions 
of unix in patch #746378.

Logged In: YES 
user_id=148712

Adding some more data points (reported by RS in the chat):

 - correct behaviour in 8.4.1, crash in 8.4.2
 
 - [proc rec args rec; rec] does not crash, even if the
recursion limit is increased to 50000 before running. (??
deduce that TpCSS basic functionality is OK ??)

 - [rename global foo; bar] does not crash (note that
[global] is the first core command called in [unknown])

Logged In: YES 
user_id=72656

FWIW, I can't crash a non-threaded build, I always get:

% lorax [~/cvs/tktable/tktable] 731 > tclsh8.4
% rename info ::tcl::info
% foo
too many nested evaluations (infinite loop?)

I've changed the subject to be more accurate.  This is about a 
problem with stack checking and recursion, not 'info' in 
particular.

Logged In: YES 
user_id=302287

I agree that this isn't recommended behaviour (renaming info
without replacement). But tcl shouldn't crash even with it.

Miguel: Those were all unthreaded builds, just one threaded
tcl842, so it isn't the same issue as with the threaded
crash on SuSE8.0 i reported.

Logged In: YES 
user_id=148712

Jeff is refering to [Bug 705917]. I tend to disagree that
this is 100% the same issue - although I did hint at it in
my comment to pat hoyt's report in the chat.

One thing we are seeing here is the failure of
TclpCheckStackSpace() on W2000 (maybe too small a safety
value TCL_WIN_STACK_THRESHOLD?).
I seem to recall TpCSS being "alloca and see if it works",
now it is inline assembly: did it get broken when changed?

Reopening ...

Michael: were those all threaded builds?

Logged In: YES 
user_id=72656

This is completely valid.  The problem is that you are 
renaming a core command without redefining it.  This 
command is used by the 'unknown' command, which is what 
gets invoked by the unknown 'foo' command.  You have to 
redefine info before that.

The crash on threaded shells with deep recursion is already 
known and has to do with limited stack set by some OSes.

File Added - 47481: info-crash2.stack

File Added - 47480: info-crash.stack