in reply to Re^4: Crash in stack_grow() with SQL::Abstract
in thread Crash in stack_grow() with SQL::Abstract

A way to create such a sized array using the smallest possible amount of memory is to create all the elements as undef. So for example
my @ary; $ary[0xFF0000000 - 1] = 1;
But this will still need at least 32Gb of virtual memory.

Which makes me wonder whether the array in your bug report ever had that many elements - does the server have that much memory? If not, then perhaps the array isn't really that size? In which case, perhaps it is tied, but the FETCHSIZE() method is returning a rogue value? Or the array has got corrupted somehow.

Dave.

Replies are listed 'Best First'.
Re^6: Crash in stack_grow() with SQL::Abstract
by Casey2255 (Initiate) on Jun 04, 2025 at 18:37 UTC

    Thank you again for your input! This is running on an embedded device with a total of 2 GiB of RAM, so nothing close to 32GB would be possible on this context.

    And for more context, the tables we're working with are TINY by cloud standards. They are all 2-3 columns and less than 200 rows in total. With that this is sounding more and more like a corrupted/uninitialized value is making its way into a call to stack_grow().

    I tried running your above example (edited to remove what I assumed was an extra 0) and got the following:

    Modification of non-creatable array value attempted, subscript -16777217 at ./test.pl line 7.