Tcl_InvalidateStringRep(objPtr) causes later crash in TclCreateLiteral
in [TCL]
|
Prev: Tcl_InvalidateStringRep(objPtr) causes later crash in TclCreateLiteral
Next: Background color for a ttk:treeview column
From: miguel sofer on 7 Apr 2010 21:28 stsoe wrote: > Hi all, > > I am using tcl8.5.6 and have run into an issue when my extension is > calling Tcl_InvalidateStringRep with a shared Tcl_Obj that happens to > be stored in Tcl's literal table. When Tcl later looks up in the > literal table for an object that matches the string rep of the earlier > invalidated object, it can happen that it reaches the object that was > earlier processed by Tcl_InvalidateStringRep. This object correctly > has bytes==0x0 but the length was not reset and remains the original > length, hence matches the length of the requested string literal. A > crash occurs when TclCreateLiteral then deferences the null bytes ptr. > > Shouldn't Tcl_InvalidateStringRep remove the objPtr from the literal > table if it is there? Or at the very least set the length to 0 at the > same time it deletes and nulls the bytes ptr ? Remove from the literal table: no. Depending on which literal table you mean, this may even be disastrous: bytecodes index into this table. Set the length to 0: not really, irrelevant. There are Tcl_Objs with 0 length anyway (the empty string), so length==0 is not a good signal for 'invalid string rep'. That is signalled by bytes==NULL. The REAL question is: why are you invalidating the string rep of a shared object? The literal code assumes that this is never done: it doesn't make a lot of sense (or else we're missing something). Remember EIAS and the COW principle: a shared object is read-only, and any changes (shimmering?) that you do to it have to preserve the string rep (which carries the real identity of the object). Miguel EIAS: Everything Is A String COW : Copy On Write |