Tcl Source Code

Tcl Version: 8.4a3 (today's HEAD)
OS: linux 2.2.19 (RH 6.2)
Compiler: egcs-2.91.66 (gcc)
Comp flags: default + "-march=pentiumpro"

Description: segfault in trace.test

  ./configure --disable-shared
  make
  make test

All is OK till here,  _but_:

[mig@mini unix]$ ./tcltest ../tests/trace.test  
Segmentation fault (core dumped)
[mig@mini unix]$ ./tcltest ../tests/trace.test -verbose
trace.test:     Total   185     Passed  185     Skipped
0       Failed  0

Categorizing as "tcltest" bug due to the different
behaviour when verbose switch is on; may well be a bug
somewhere else though ...

Logged In: YES 
user_id=80530

committed to HEAD.

Logged In: YES 
user_id=79902

The tclCmdMZ.c changes look OK to me (the preservations are
all done on internal structures so there are no non-obvious
requirements on extensions using command traces, which is
what I was really looking for.)  Assigning back to Don for
commit (and ChangeLog entry, which is main thing missing.)

Logged In: YES 
user_id=148712

The patch lokks fine to me; testsuite approves too, on
linux. As it patches tclCmdMZ.c, I'll ask Donal to give his
OK too before committing.

File Added - 13607: cmdtrace.patch

Logged In: YES 
user_id=80530

Here's the patch.  Assigning to maintainer for review and
commit.

Logged In: YES 
user_id=80530

Now that TIP 68 took care of the big problem, we
can focus again on clearing away all memory problems
with traces.

Running the test suite with ElectricFence reveals
that CallCommandTraces() in tclBasic.c needs some
Tcl_Preserve() calls.  Patch coming soon.

Logged In: YES 
user_id=79902

219393 is a nasty bug, but fixing it will require an API
change.  In my spare moments (hah!) I'm working on the TIP
required...

Logged In: YES 
user_id=80530

Not to worry, Jeff.  You haven't caused anything to go
wrong.

There's a memory corruption bug in the machinery of
[trace].  I believe it's the bug described in 219393.
The bug's existence is constant.  The bugs visibility
during 'make test' comes and goes depending on how
unrelated code changes shift the memory corruption into
areas where it does/doesn't matter.  The commits of
2001-09-19 shifted it back into visibility for me.

As we've established many times before, the memory allocator
on Linux/Alpha tends to re-use freed memory more rapidly
than many other platforms, so memory corruption bugs 
often make themselves visible only there.

Logged In: YES 
user_id=72656

which latest commits?  I still don't see anything (nor did 
I before) on Linux or Windows.

Logged In: YES 
user_id=80530

Latest commits brought back memory corruption
in test trace-9.1 for me.  Did it bring back
segfaults for others?

Increasing priority, so I'll actually get around
to fixing this.

Logged In: YES 
user_id=80530

Don't close it.  I confirm that the CVS HEAD
no longer demonstrates the bug while
running the trace.test, but in another
patched version of Tcl, I do still see a
segfault in trace.test.  There's still a
memory corruption problem in there.

It might be the one identified in bug
219393, or it's possible it could be 
another one.  Let's check again after
219393 is fixed.

Logged In: YES 
user_id=148712

It's a miracle, the bug seems to have fixed itself! I cannot
reproduce it anymore with today's HEAD.

As nobody seems to have found a probable cause, I'd be
tempted to "close" or at least "works for me" the ticket if
the segfault can't be reproduced. 

Assigning to Don: is it also fixed in your setup?

Logged In: YES 
user_id=32170

With both debug and release builds and with and without '-
verbose' I can't reproduce this on my Win2000 setup, so I'm 
afraid I'm not going to be able to help.  I really can't 
think what can have changed here.

Logged In: YES 
user_id=80530

Patch 402501 is now updated.

Logged In: YES 
user_id=32170

I have to say I have no obvious ideas of how the 8.4 
changes would have affected this at all.  I've never seen 
the problem, but can try to reproduce it.

Logged In: YES 
user_id=80530

Does application of Patch 402501 have any
effect on solving this bug?

Logged In: YES 
user_id=148712

Vince: any ideas?

Logged In: YES 
user_id=148712

Doh ... today's head would be 8.4a4, not 8.4a3!

Logged In: YES 
user_id=80530


This is very likely related to bug 219393.

I don't see segfaults, but:
trace.test:     Total   185     Passed  185     Skipped
0      
Failed  0
clover:unix: ./tcltest ../tests/trace.test -verbose

==== trace-9.1 be sure variable is unset before trace is
called FAILED
==== Contents of test case:

    catch {unset x}
    set x 33
    set info {}
    trace add variable x unset {traceCheck {uplevel set x}}
    unset x
    set info

---- Result was:
1 {can't read "x": no such variaale}
---- Result should have been (exact matching):
1 {can't read "x": no such variable}
==== trace-9.1 FAILED

trace.test:     Total   185     Passed  184     Skipped
0       Failed  1

Note the memory corruption mangling the error message.

Logged In: YES 
user_id=72656

This is likely due to a bug in the actual trace changes in 
8.4, which should be hunted down.  Assigning back to Miguel 
since he can reproduce this.  Might need to go to Vince.