Tcl Source Code

out of memory panics are one thing, but
really big list lengths appear to produce
a different segfault:

        % lrepeat [expr {1<<25}] a; concat
% lrepeat [expr {1<<26}] a; concat
unable to alloc 268435456 bytes
Abort
% lrepeat [expr {1<<28}] a; concat
unable to alloc 2147483648 bytes
Abort
hamming:solaris: ./tclsh
% lrepeat [expr {1<<29}] a; concat
Segmentation fault

Logged In: YES 
user_id=79902

Fixed (as far as I can tell - these
memory-allocation-failure things are awkward for me to test
for assorted not very nice reasons) and
performance-engineered a bit at the same time.

Logged In: YES 
user_id=79902

[lrepeat] really ought to soft-fail when insufficient memory
is available, but doing that is tricky because you have to
tell the list constructor that it now has ownership of an
array, instead of the current technique which is a copy. 
OTOH, there is definitely still utility in allocating such
arrays since you can use [lset] to manipulate them safely.

Sounds like a new (internal) function: TclNewListObjDirect()

Logged In: YES 
user_id=79902

SEGV's bad; boosting prio

File Added - 65247: 829027.patch

Logged In: YES 
user_id=80530


The usage of attempckalloc
is trickier than it first appears,
given the use of ckalloc within
the Tcl_ListObj* routines.

Here's a patch dealing with
just the original report.

Logged In: YES 
user_id=80530


Use of attemptckalloc leading to a
TCL_ERROR and error message
when insufficient memory would
also be better than the panic.

Logged In: YES 
user_id=80530


Also contributing is that there's
a sizeof(Tcl_Obj) where there should
be a sizeof(Tcl_Obj *).

Logged In: YES 
user_id=80530


This appears to be integer
overflow in the argument to
ckalloc().  As observed in the chat:

jenglishWith 32-bit ints, (1 << 30) * sizeof(int) == (1 <<
32) == 0.