Tcl Source Code

% lindex [info patchlevel] 0]
Tcl_AppendStringsToObj called with shared object

Program received signal SIGABRT, Aborted.
0x200003976e8 in __kill () at __kill:2
2       __kill: No such file or directory.
(gdb) bt
#0  0x200003976e8 in __kill () at __kill:2
#1  0x200003973b8 in raise (sig=6) at
../sysdeps/posix/raise.c:27
#2  0x200003992d8 in abort () at
../sysdeps/generic/abort.c:88
#3  0x120013d8c in Tcl_PanicVA (
    format=0x1200f5bae "Tcl_AppendStringsToObj called
with shared object", 
    argList={__base = 0x11fffed00 "®[\017 \001",
__offset = 72})
    at ./../generic/tclPanic.c:106
#4  0x120013e4c in Tcl_Panic (
    arg1=0x1200f5bae "Tcl_AppendStringsToObj called
with shared object")
    at ./../generic/tclPanic.c:134
#5  0x12001ccbc in Tcl_AppendStringsToObjVA
(objPtr=0x120226ed0, argList={
      __base = 0x11fffeeb0 "Ðn\" \001", __offset = 8})
    at ./../generic/tclStringObj.c:1389
#6  0x12001d0ec in Tcl_AppendStringsToObj
(arg1=0x120226ed0)
    at ./../generic/tclStringObj.c:1525
#7  0x120024e00 in TclGetIntForIndex
(interp=0x120215e90, objPtr=0x120226150, 
    endValue=0, indexPtr=0x11fffef54) at
./../generic/tclUtil.c:2234
#8  0x120046b9c in TclLindexList (interp=0x120215e90,
listPtr=0x120226ed0, 
    argPtr=0x1202261b0) at ./../generic/tclCmdIL.c:2170
#9  0x1200859e4 in TclExecuteByteCode
(interp=0x120215e90, codePtr=0x120225c20)
    at ./../generic/tclExecute.c:2562
#10 0x12007c7c8 in TclCompEvalObj (interp=0x120215e90,
objPtr=0x120226b70, 
    engineCall=0) at ./../generic/tclExecute.c:941
#11 0x1200362dc in Tcl_EvalObjEx (interp=0x120215e90,
objPtr=0x120226b70, 
    flags=131072) at ./../generic/tclBasic.c:3866
#12 0x120099344 in Tcl_RecordAndEvalObj
(interp=0x120215e90, 
    cmdPtr=0x120226b70, flags=131072) at
./../generic/tclHistory.c:142
#13 0x12000fe68 in Tcl_Main (argc=1, argv=0x11ffff588, 
    appInitProc=0x12000f440 <Tcl_AppInit>) at
./../generic/tclMain.c:400
#14 0x12000f41c in main (argc=1, argv=0x11ffff588) at
./../unix/tclAppInit.c:99


Problem appears to be appending to the interpreter's
object result, when that Tcl_Obj is shared.

Tcl_AppendStringsToObj(Tcl_GetObjResult(interp)... 
is a *very* common idiom throughout the Tcl source
code, and checks for Tcl_IsShared() are very rare.
Are these all bugs waiting to be exercised, or is
there some convention we follow to avoid trouble?

Logged In: YES 
user_id=148712

This ticket's bug is fixed.
The more general "appending to the result obj without
checking if it is shared throughout the source" remains as
it was.

Logged In: YES 
user_id=148712

the fix for [Bug 781585] has an effect on this: TEBC now
(8.5a0 - 8.4.x, x>4)  never shares the interp's result,
which reduces the probability of failure of the unshared
assumption.
But it is stillnot a fix ...

Logged In: YES 
user_id=72656

I can't reproduce with the simple lindex with bad index
above, so I'm dropping the prio and assuming this is OK ... ???

Logged In: YES 
user_id=79902

The problem's still there, though you must remember to type
in a *bad* index to pass to [lindex].  However, I'm checking
in a fix for this.

It is not a general fix; the real problem is that lots of
places in the core want to generate results incrementally
and the current recommended APIs make this harder to do
safely than it ought to be.  We *really* should try to fix
this before 8.4.0

(Dropping the priority back so the bug doesn't block 8.4b1)

Logged In: YES 
user_id=148712

It's still there ...

Logged In: YES 
user_id=80530

Is this resolved now?

I do not see the original failure with the HEAD sources.

Logged In: YES 
user_id=148712

I think this is a symptom of the same "disease" described in
bugs #456892 and #550142. Raising the priority.

File Added - 19827: 533364.patch0

Logged In: YES 
user_id=148712

The enclosed one-line patch0 solves this (and every other)
such issue: insure that the bc engine clears the result
*before every instruction*. 
The problem is that some library calls from the engine may
leave a result, so that it is not enough to clear the result
before running a bytecode. One alternative would be to have
the compiler generate a "clear result" before every bcc'ed
command. 

Both of these look unnecessarily expensive to me. I'd like
to think a little more before commiting to this solution
path.

Logged In: YES 
user_id=148712

I remember thinking that that particular idiom should be
changed to
   Tcl_SetObjResult(interp, Tcl_NewStringObj(...))
in just about every occurrence, as it appears mostly in
places where a result (or error) is being generated, relying
on having an unshared "" in the interp result. I'll look
again - after fixing this particular problem.