Tcl Source Code

View Ticket
Login
Ticket UUID: 959193
Title: interp-34.7 panic
Type: Bug Version: obsolete: 8.5a2
Submitter: dgp Created on: 2004-05-24 01:46:25
Subsystem: 20. [interp] Assigned To: dkf
Priority: 8 Severity:
Status: Closed Last Modified: 2004-05-25 04:49:55
Resolution: Fixed Closed By: dkf
    Closed on: 2004-05-24 21:49:55
Description:
(gdb) run ../tests/all.tcl -file interp.test -match
interp-34.7 -singleproc 1
Starting program: /local/src/tcl/debug/./tcltest
../tests/all.tcl -file interp.test -match interp-34.7
-singleproc 1
Tests running in interp:  /local/src/tcl/debug/./tcltest
Tests located in:  /local/src/tcl/tests
Tests running in:  /local/src/tcl/debug
Temporary files stored in /local/src/tcl/debug
Test files sourced into current interpreter
Running tests that match:  interp-34.7
Skipping test files that match:  l.*.test
Only running test files that match:  interp.test
Tests began at Sun May 23 09:43:17 PM EDT 2004
interp.test
unknown type of resource limit

Program received signal SIGABRT, Aborted.
0x200003956e8 in __kill () at __kill:2
2       __kill: No such file or directory.
(gdb) bt
#0  0x200003956e8 in __kill () at __kill:2
#1  0x200003953b8 in raise (sig=6) at
../sysdeps/posix/raise.c:27
#2  0x200003972d8 in abort () at
../sysdeps/generic/abort.c:88
#3  0x1200d658c in Tcl_PanicVA (format=0x120140b6a
"unknown type of resource limit", 
    argList={__base = 0x11fffb1e0 "j\013\024 \001",
__offset = 72})
    at ../unix/../generic/tclPanic.c:105
#4  0x1200d664c in Tcl_Panic (arg1=0x120140b6a "unknown
type of resource limit")
    at ../unix/../generic/tclPanic.c:133
#5  0x1200a4598 in Tcl_LimitRemoveHandler
(interp=0x1203e8df8, type=1633771873, 
    handlerProc=0x1200a4e00 <CallScriptLimitCallback>,
clientData=0x120411068)
    at ../unix/../generic/tclInterp.c:2796
#6  0x1200a51ec in TclDecommissionLimitCallbacks
(interp=0x1203c1748)
    at ../unix/../generic/tclInterp.c:3156
#7  0x120027bd0 in DeleteInterpProc (interp=0x1203c1748)
    at ../unix/../generic/tclBasic.c:992
#8  0x1200e75e4 in Tcl_Release (clientData=0x1203c1748)
    at ../unix/../generic/tclPreserve.c:240
#9  0x1200a3258 in SlaveEval (interp=0x1202652c8,
slaveInterp=0x1203c1748, objc=1, 
    objv=0x11fffb720) at
../unix/../generic/tclInterp.c:2197
#10 0x1200a2b68 in SlaveObjCmd (clientData=0x1203c1748,
interp=0x1202652c8, objc=3, 
    objv=0x11fffb710) at
../unix/../generic/tclInterp.c:2003
#11 0x12002b000 in TclEvalObjvInternal
(interp=0x1202652c8, objc=3, objv=0x11fffb710, 
    command=0x1203bacd7 "$i eval {\n\t$i eval {\n\t   
for {set i 0} {$i<10} {incr i} {foo}\n\t}\n    }\n   
list $n [interp exists $i]\n", length=72, flags=0)
    at ../unix/../generic/tclBasic.c:3146
#12 0x12002c098 in Tcl_EvalEx (interp=0x1202652c8, 
    script=0x1203babd8 "\n    set subi [$i eval set
i]\n    interp alias $i trapToParent {} cb3\n    set n
0\n    $i eval {\n\tset a 0\n\tset b 0\n\tset c
a\n\tinterp alias $i foo {} cb1\n\tset curlim [$i eval
info cmdcount]\n\t$i limit com"..., numBytes=358, 
    flags=262144) at ../unix/../generic/tclBasic.c:3644
#13 0x12002c6d4 in Tcl_EvalObjEx (interp=0x1202652c8,
objPtr=0x120381498, flags=262144)
    at ../unix/../generic/tclBasic.c:3878
#14 0x1200e8d64 in Tcl_UplevelObjCmd (dummy=0x0,
interp=0x1202652c8, objc=1, 
    objv=0x1202663c8) at ../unix/../generic/tclProc.c:664
#15 0x12002b000 in TclEvalObjvInternal
(interp=0x1202652c8, objc=3, objv=0x1202663b8, 
    command=0x0, length=0, flags=0) at
../unix/../generic/tclBasic.c:3146
#16 0x12007f48c in TclExecuteByteCode
(interp=0x1202652c8, codePtr=0x120408368)
    at ../unix/../generic/tclExecute.c:1666
#17 0x12007cc24 in TclCompEvalObj (interp=0x1202652c8,
objPtr=0x12032ef78)
    at ../unix/../generic/tclExecute.c:1005
#18 0x1200e9934 in TclObjInterpProc
(clientData=0x1202f3488, interp=0x1202652c8, objc=3, 
    objv=0x1203e1288) at ../unix/../generic/tclProc.c:1088
...
etc.

more stack trace available on request.
User Comments: dkf added on 2004-05-25 04:49:55:
Logged In: YES 
user_id=79902

D'oh!  I was *sure* that the docs said that
Tcl_InitHashTable() said structs were in terms of
pointer-words, not ints.  I was wrong.  Fixed.

dgp added on 2004-05-24 23:50:15:

File Added - 88254: 959193.patch

Logged In: YES 
user_id=80530


This patch appears to fix the problem.
Please review.

dkf added on 2004-05-24 22:34:32:
Logged In: YES 
user_id=79902

Analysis of the trace indicates that this is a Free Memory
Read.  I'm not surprised at that, but I'd love to know
what's causing the problem. :^/

dkf added on 2004-05-24 15:44:19:
Logged In: YES 
user_id=79902

I know there is some kind of problem here (that particular
test is supposed to test a particularly nasty path leading
to limit callback deletion) but I really can't figure out
where the fault is happening.  If someone could let me have
some Purify and/or EFence output doing this test, that'd be
*immensely* helpful.

Attachments: