[Bug gdb/34132] gdb memory corruption and crash when trying to print large float arrays
tromey at sourceware dot org
sourceware-bugzilla@sourceware.org
Thu May 7 12:47:13 GMT 2026
https://sourceware.org/bugzilla/show_bug.cgi?id=34132
--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
The bug is that value::allocate_contents throttles the size
if (check_size)
{
/* If we are allocating the contents of an array, which
is greater in size than max_value_size, and there is
an element limit in effect, then we can possibly try
to load only a sub-set of the array contents into
GDB's memory. */
if (type () == enc_type
&& type ()->code () == TYPE_CODE_ARRAY
&& len > max_value_size
&& set_limited_array_length ())
len = m_limited_length;
else
check_type_length_before_alloc (enc_type);
}
... but value_repeat (or maybe read_value_memory -- not sure where
the check should be) does not respect this.
Another possibility is that allocate_repeat_value should pass
check_size=false to skip the throttling. Though, normally, the
size check is good, since really not all 10000000 members will
be printed.
Speaking of, eval_op_repeat does this:
if (noside == EVAL_AVOID_SIDE_EFFECTS)
{
return allocate_repeat_value (arg1->type (),
longest_to_int (value_as_long (arg2)));
}
but here allocating the full size seems useless. This could allocate
a lazy value instead. So maybe another possibility is having
allocate_repeat_value return a lazy value and let the usual value-filling
approach happen.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Gdb-prs
mailing list