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.

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)

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.