Tcl Source Code

View Ticket
Login
Ticket UUID: 467505
Title: embedded interp crashes on win 2000
Type: Bug Version: obsolete: 8.3.2
Submitter: deech Created on: 2001-10-03 14:40:37
Subsystem: 27. Channel Types Assigned To: davygrvy
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2002-05-28 12:29:22
Resolution: Invalid Closed By: davygrvy
    Closed on: 2002-05-28 05:29:22
Description:
A very simple test program has been attached that 
crashes on windows 2000, after being compiled with VC6 
(sp5). This has been tested on two win 2000 machines 
with consistent behaviour.

 This code successfully Evals some commands, 
(i.e. "puts $auto_path") but crashes on many other 
commands. A couple of these other commands have been 
included with in the comments of the source code.

This has also been tested on windows NT compiled under 
VC5 (sp3) and works fine (i.e. No Crash!).
User Comments: davygrvy added on 2002-05-28 12:29:22:
Logged In: YES 
user_id=7549

Calls to Tcl_Eval() must use writable strings as per the docs.

r = Tcl_Eval(g_interp, "puts [info patchlevel]");

that is guarenteed crash.  Change it to this:

char cmd[] = "puts [info patchlevel]";
r = Tcl_Eval(g_interp, cmd);

andreas_kupries added on 2001-12-12 01:18:10:
Logged In: YES 
user_id=75003

David, I just compared the head of tcl (8.4.aXXX) against 
the head of core-8-3-1-branch (= head of 8.3.4+) and the 
only difference I saw in "tclWinChan.c" was an adaption 
of "TclpOpenFileChannel" to the new VFS 
code. "Tcl_MakeFileChannel" is the same in both files. And 
I am unable to see the big __try/__except sections you are 
refering too. Can you give me line numbers ? Is that the 
code for FILE_TYPE_UNKNOWN where you try to dup a handle to 
check its validity ?

Assigned to you so that you see my question.

dgp added on 2001-11-10 02:55:51:
Logged In: YES 
user_id=80530

Judging from davygrvy's comments, the trouble
here is in Tcl's handling of std channels
on Win2K.  Assigning to that category.

davygrvy added on 2001-11-07 14:00:50:
Logged In: YES 
user_id=7549

PS.

where they both land together is here, BTW:
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), msg, _tcslen(msg), &dwWritten, NULL);

And GetStdHandle(STD_OUTPUT_HANDLE) returns garbage on Win2K within a GUI application.

davygrvy added on 2001-11-07 13:57:15:
Logged In: YES 
user_id=7549

Ok, you are using a console app.  Sorry about my GUI comments.

I don't think you should be mixing Tcl_WriteObj() [<- the deep end of puts] and cout.  I have some stream code that'll set cout to use Tcl_WriteObj() instead, if you want it (?)

They do eventually land in the same place, but take very different paths to get there.  I've always been leary of mixing the two, but I can't say it is wrong, either.

davygrvy added on 2001-11-07 13:46:14:
Logged In: YES 
user_id=7549

The bug is in Win2K and Tcl.  Tcl_MakeFileChannel() was repaired in 8.4 more than a year ago.

The STARTUPINFO handed to the GUI application that embedds Tcl, has invalid data in the 3 standard handles:

.hStdInput
.hStdOutput
.hStdError

They were previously accepted without question and only tested if == NULL || == INVALID_HANDLE_VALUE.  But Win2K
is putting garbage there.  See Tcl_MakeFileChannel() in tclWinChan.c (HEAD code in CVS) for the big effort I did with __try/__except.

A possibly better check might be to use HasConsole() first, to see if the data in the STARTUPINFO should be worth checking.  The belt and suspender exception handling in Tcl_MakeFileChannel() could be left in place, though.

The error you should be getting is:
can not find channel named "stdout"

[puts ""] will never work in your case anyways, as there is no destination in a GUI application unless it calls AllocConsole() to create one.

I'll have a look at your code...

deech added on 2001-10-03 23:23:07:
Logged In: YES 
user_id=339882

With further investigation, it seems this also happens with 
the latest version of tcl (8.4a3) on windows 2000. 

"Normal" tcl commands seems to function, (i.e. puts, for, 
if...) the 'info' command seems to consistently crash the 
interpreter, as well attempting to access functions in 
loaded packages also seems to crash the interpreter. 

Ex. package require simple            //functions fine
    puts [simple::upper SoMeStRiNg]   //unhandled exception

deech added on 2001-10-03 21:40:39:

File Added - 11523: TclEmbedEx.cpp

Attachments: