Tcl Source Code

This shouldn't core-dump!

% info patch
8.4a4
% set x(bar) 0
0
% trace variable x r {set x(foo) 1 ;#}
% trace variable x r {unset -nocomplain x(bar) ;#}
% trace vinfo x
{r {unset -nocomplain x(bar) ;#}} {r {set x(foo) 1 ;#}}
% array get
x                                                                              
": no such element in array
% array get x
Segmentation fault (core dumped)

Logged In: YES 
user_id=148712

Docs added to array.n

Logged In: YES 
user_id=148712

Re docs: or with [trace]? Or both?
It is a really something that is relevant to the interplay
between [array get] and [trace] - when there are read traces
on an array that either add or remove an element of the
array.

I'm also not 100% happy with the error message when the
trace unsets the whole array (see test trace-1.13 ): should
it rather return {} and no error as does [array get
nonExistingArray] ?

Reopening the ticket, with lower priority now that the
segfault is gone ...

Logged In: YES 
user_id=80530

the patch included no doc changes.  Is there a
best place to document the particular behavior?
In the [array get] docs, perhaps?

Logged In: YES 
user_id=148712

Patch committed to HEAD.

File Added - 14049: arrayGet.patch

Logged In: YES 
user_id=148712

It is difficult to define what the correct behaviour of
[array get]
should be when there are read traces that modify the array 
structure. 

In discussions on the Tcl'ers Chat with Kevin Kenny and 
Don Porter we agreed that a (the only ?) reasonable
behaviour 
is given by

 proc array-get { aName } {
     set result [list]
     upvar 1 $aName array
     foreach s [array names array] {
         if { [info exists array($s)] } { 
     # because a trace could have deleted it 
             lappend result $s $array($s)
         }
     }
     return $result
 }

The enclosed patch implements this behaviour and adds three
tests 
for it. These tests cause illegal memory behaviour without
the patch 
to tclVar.c - an access to a previously disposed Tcl_Obj is
detected 
by TCL_MEM_DEBUG.

Logged In: YES 
user_id=80530

Note, a very similar script causes a segfault
in Tcl 8.3.3.  (Change [unset -nocomplain ...]
to [catch {unset ... )

Logged In: YES 
user_id=148712

Bug is also present in 8.3.3 and 8.0.5.