Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-2802881 ] segfault with trace on ::errorInfo
|
From: SourceForge.net <no...@so...> - 2009-06-10 23:08:34
|
Bugs item #2802881, was opened at 2009-06-08 08:05 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2802881&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 47. Bytecode Compiler Group: current: 8.5.7 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: miguel sofer (msofer) Assigned to: miguel sofer (msofer) Summary: segfault with trace on ::errorInfo Initial Comment: (see http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/eb5ee89cc9450b52#) The following script causes a segfault: set ::errorLevel -1 set ::errorStack {} trace add variable ::errorInfo write { set __n [info level] if {($__n > 0) && ($__n != $::errorLevel)} { set ::errorLevel $__n set __l [info level 0] lappend ::errorStack $__l } } proc A {} {if {foo} foo} A 0 A stack trace shows that the fault is in INST_LOAD_SCALAR1 (TEBC line 2552) while running the trace script. The problem is that the trace script doesn't have any local variables, this instruction shouldn't have been compiled in. The compilation is faulty: at the time of the crash we see that the bytecode has a non-NULL codePtr, which is wrong: (gdb) p *codePtr $1 = {interpHandle = 0x7548d0, compileEpoch = 3, nsPtr = 0x754ad0, nsEpoch = 0, refCount = 2, flags = 0, source = 0x780e80 "($__n > 0) && ($__n != $::errorLevel)", procPtr = 0x7ac900, structureSize = 47393536776768, numCommands = 0, numSrcBytes = 37, numCodeBytes = 22, numLitObjects = 4, numExceptRanges = 0, numAuxDataItems = 0, numCmdLocBytes = 0, maxExceptDepth = 0, maxStackDepth = 2, codeStart = 0x7741f0 "\n", objArrayPtr = 0x774208, exceptArrayPtr = 0x0, auxDataArrayPtr = 0x0, codeDeltaStart = 0x774228 "\ufffd\ufffdz", codeLengthStart = 0x774228 "\ufffd\ufffdz", srcDeltaStart = 0x774228 "\ufffd\ufffdz", srcLengthStart = 0x774228 "\ufffd\ufffdz", localCachePtr = 0x0} (gdb) p *codePtr->procPtr->bodyPtr $2 = {refCount = 1, bytes = 0x780c00 "if {foo} foo", length = 12, typePtr = 0x0, internalRep = {longValue = 8043008, doubleValue = 3.9737739420263127e-317, otherValuePtr = 0x7aba00, wideValue = 8043008, twoPtrValue = {ptr1 = 0x7aba00, ptr2 = 0x0}, ptrAndLongRep = {ptr = 0x7aba00, value = 0}}} The CallFrame does look ok: (gdb) p *((Interp *)interp)->varFramePtr $3 = {nsPtr = 0x754ad0, isProcCallFrame = 0, objc = 0, objv = 0x0, callerPtr = 0x754ed0, callerVarPtr = 0x754ed0, level = 1, procPtr = 0x0, varTablePtr = 0x0, numCompiledLocals = 0, compiledLocals = 0x0, clientData = 0x0, localCachePtr = 0x0} ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2009-06-10 19:07 Message: just confirmed this crashes the 8-4-branch too. and the 8.4.19 release too. and the 8.4.8 release too. and 8.4.0 too. This isn't some flaw in recent development. Which also suggests this is not old code getting broken by more recent Tcl releases. That is, this is new code. In that case, my advice is Don't Do That. New code should target Tcl 8.5 and code with the features of Tcl 8.5 available need not make any use of the ::errorInfo or ::errorCode variables at all. So don't use them. I'm still curious about what's going on, and will try to track it down and fix it. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-06-08 10:40 Message: More precisely: - is it desirable that CompileScript calls Tcl_ResetResult ? - is it desirable that Tcl_ResetResult calls the trace_enabled Tcl_SetVarXX on errorCode and errorInfo ? ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-06-08 09:08 Message: Yes, as suggested in the thread, the trace is called during *compilation* (as shown by ::tcl::unsupported::disass). >From my seat, this mere fact sounds very very wrong. Am I mistaken ? (excerpt from backtrace in gdb:) #10 0x00296ea7 in TclCallVarTraces () from ./libtcl8.6.so #11 0x002970d6 in TclObjCallVarTraces () from ./libtcl8.6.so #12 0x0029cfc1 in TclPtrSetVar () from ./libtcl8.6.so #13 0x0029f910 in Tcl_ObjSetVar2 () from ./libtcl8.6.so #14 0x0028a654 in Tcl_ResetResult () from ./libtcl8.6.so #15 0x00230bdf in TclCompileScript () from ./libtcl8.6.so ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2009-06-08 08:19 Message: The stack trace is (gdb) bt 5 #0 0x00000000004ec601 in TclExecuteByteCode (interp=0x754400, codePtr=0x7b6400) at /home/CVS/tcl-core-8-5-branch/unix/../generic/tclExecute.c:2552 #1 0x00000000004e9a59 in Tcl_ExprObj (interp=0x754400, objPtr=0x7ab5b0, resultPtrPtr=0x7fffea3bc910) at /home/CVS/tcl-core-8-5-branch/unix/../generic/tclExecute.c:1262 #2 0x000000000048a86b in Tcl_ExprBooleanObj (interp=0x754400, objPtr=0x7b6400, ptr=0x7fffea3bc990) at /home/CVS/tcl-core-8-5-branch/unix/../generic/tclBasic.c:5387 #3 0x00000000004973f5 in Tcl_IfObjCmd (dummy=0x0, interp=0x754400, objc=3, objv=0x7557a0) at /home/CVS/tcl-core-8-5-branch/unix/../generic/tclCmdIL.c:233 #4 0x000000000048821c in TclEvalObjvInternal (interp=0x754400, objc=3, objv=0x7557a0, command=0x7b991e "if {($__n > 0) && ($__n != $::errorLevel)} {\n set ::errorLevel $__n\n set __l [info level 0]\n lappend ::errorStack $__l\n }\n::errorInfo {} write", length=146, flags=0) at /home/CVS/tcl-core-8-5-branch/unix/../generic/tclBasic.c:3690 ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2009-06-08 08:14 Message: Interesting: the BODY of A seems to make a difference, even though it is never run due to the error in the number of args! % proc A {} {} % A 0 wrong # args: should be "A" % proc A {} {foo} % A 0 wrong # args: should be "A" % A invalid command name "foo" % proc A {} {if {foo} foo} % A 0 Segmentation fault (core dumped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2802881&group_id=10894 |