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

One more... Can you run a test on the target hardware that pushes an insane number of things onto the stack and see what message it crashes with?

The reason I ask is that it's possible to produce automatic SQL that does WHERE column IN (?, ?, ?, ?, ............, ?) where it generated a placeholder for each of millions of rows that came from another resultset, so you could legitimately run out of Perl stack on that function call if you're now asking the perl stack to grow to match that array's length.

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

    Thank you for the input!

    Forgive my ignorance of the guts, if there is a better way to expand the stack pathologically without the `x` operator, please advise. I tested the following on the hardware: 

    #!/usr/bin/perl

use strict;
use warnings;

sub test {
    my @arr = (1) x 0xFF000000;
    return @arr;
}

test()

    [download]
    The results of that script on the hardware is an instant OOM.
    Out of memory during list extend at ./test.pl line 8.
    If I instead drop the value down to 0x0F000000 it gets reaped by the OOM killer after 5-6 seconds.
    [14975.456522] Out of memory: Killed process 26695 (test.pl)
[reply]
[d/l]
      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;

      [download]
      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.

[reply]
[d/l]

        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.
[reply]

In Section Seekers of Perl Wisdom