Tcl Source Code

TclKit still has a crash on exit reported by several
people on Win 9x.

I'm now able to consistently reproduce it, with latest
CVS head of everything, and running a starkit with the
tkhtml extension in it -
http://www.equi4.com/pub/sk/tcl84dok.kit

Not sure any of this is crucial, but the above combo
consistently crashes on win98se and does not crash on
nt4 (both under vmware).

I haven't got a debug build of the latest tclkit with
MSVC6, but I did manage to get a link map and a
drwatson log, which - with a bit of hunting - indicates
this problem happens with code in tclEncoding.c, i.e.
encoding cleanup order or something.

TclKit plays one trick with encodings: it has its own C
command which calls TclSetLibraryPath, then
TclpSetInitialEncodings, then Tcl_FindExecutable (all
is in tclkit src/pwb.c, a trivial wrapper).

This is needed to resolve the startup catch-22: create
tcl interp, then run some setup scripts, then tclkit's
end-of-exe data is available as mounted VFS, and *then*
we need to reset the encoding logic so it will find
encodings inside VFS.  Twisted, but it seems to work
because there is logic in the startup of encodings to
allow initing twice.

Now the punch line: if I remove the call to
TclpSetInitialEncodings from src/pwb.c, i.e. tclkit's
"librarypath" command, then it no longer crashes on
exit.  Put it back in: boom.

Unfortunately, leaving that call out also means the
system encoding does not get set to cp1252 on 98 (on
nt4 it is still fine) - I can easily fix it, though its
unfortunate that the automatic choice for win (and
maybe mac?) gets lost.

Bottom line: I will remove the call to
TclpSetInitialEncodings, and add fake logic to pick
cp1252 on windows (probably incorrect for international
window configs).  That way I hope to resolve the
crash-on-exit once and for all.

But there's deep misery behind all this, and probably
also some hideously bad logic in there... maybe the
above helps resolve the true issues underneath.

Logged In: YES 
user_id=32170

Committed fix to this cleanup sequence problem.  No if only
we had a solution to Tcl's incredible initialisation
complexities.... ;-)

Logged In: YES 
user_id=32170

Encodings do use files, but *not* during finalization.  
Therefore it is ok to move the finalization order.  
Regarding the panic proc, perhaps that should be moved 
to after both filesystem and encoding finalization.

The crash on exit that has been observed was not 
a 'panic', FWIW.

Logged In: YES 
user_id=72656

I'm not entirely confident that this patch is correct, rather than 
just masking the issue.  It moves the finalization of the 
encoding stuff after the panic proc is set to nothing.  Is it now 
just avoiding a panic?

Also, is it the early freeing that needs to be avoided, or does 
the actual encoding subsystem need to be finalized after the 
file system?  The latter seems dangerous as encodings use 
files as well, but perhaps in an innocuous manner.

Logged In: YES 
user_id=32170

Upping the priority to make sure this gets in 8.4.1.

Logged In: YES 
user_id=32170

Jeff,

Can you take a look at this suggested change.  I don't 
see any side-effects that could be bad, but don't 
understand Tcl's exit process sufficiently to be sure.

If you think it is ok, please commit.

Vince.

File Added - 33048: tclenc.diff

Logged In: YES 
user_id=1983

Perfect - I should not have been so stubborn... it works!

Terrific, attached is a patch to generic/tclEvent.c - thanks
you :)

Logged In: NO 

I don't think reseting the system encoding is really the 
thing to do --- it may get rid of a crash, but replace it 
with undefined, weird behaviour through something 
being fooled into using an encoding it doesn't want to.  
The problem appears to be that TclFinalizeFilesystem 
needs the right encoding to exist, so why don't we just 
let that encoding exist?

So, I would suggest moving the block of code as I 
suggested....

Logged In: YES 
user_id=1983

Progress - taking TclFinalizeEncodingSubsystem *out* makes
the crash disappear, even when I restore all my previous
code, i.e. the changes in pwb.c!

So for now, my workaround is to not call TFES.  I'm not sure
moving things as yoiu describe will do it, since by then VFS
is gone.  Hopefully someone else can comment on that.

My hunch is that TFES is not quite right yet.  Maybe Tcl
should reset the encoding to a built-in one, then finish
finilization at a later date?  I.e. a two-step process.

As I said, for now I'll just leave it out and live with the
mem-leak - it's exit time anyway.

Yippie - this may well be the crash-on-exit !

Logged In: YES 
user_id=32170

I don't really understand Tcl's exit process well enough 
to suggest what should be changed.  I would suggest 
trying to move this block:

TclFinalizeEncodingSubsystem();

if (tclExecutableName != NULL) {
    ckfree(tclExecutableName);
    tclExecutableName = NULL;
}
if (tclNativeExecutableName != NULL) {
    ckfree(tclNativeExecutableName);
    tclNativeExecutableName = NULL;
}
if (tclDefaultEncodingDir != NULL) {
    ckfree(tclDefaultEncodingDir);
    tclDefaultEncodingDir = NULL;
}

to after 'TclFinalizeFilesystem()', but am not sure if that 
is ok...  (tclEvent.c, around line 830 onwards).

Logged In: YES 
user_id=1983

AHA!!!

When I do the above, the crash comes back.  When I do *not*
switch to the cp1252 in boot.tcl, there is again no crash.

Maybe the conclusion is a completely different one: maybe we
simple need to find a spot to reset the encoding to
something harmless, such as iso8859-1 or identity suring the
exit process?  The encodings are in VFS which at some point
becomes unavailable.

Vince - could you suggest a spot, and perhaps the code too,
where and how reset encodings?  As late as possible, I
suppose - but no later.  In Tcl's C code, since we want to
catch all exit paths.

I sense victory not too far around the corner :)

File Added - 32963: kit.map.gz

Logged In: YES 
user_id=1983

Oops, should have compressed the link map - here it is.

File Added - 32962: kit.crash