[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