in reply to Crash in stack_grow() with SQL::Abstract

Perl_stack_grow() is a C function: it's part of the perl interpreter. You would have to debug it by using a C debugger such as gdb and run the perl interpreter under it.

It will be called each time an OP being being executed by the interpreter wants to push one or more items onto perl's argument stack. In that line of code, it likely extends it by 1 to push $clauses_aref->[0] and then extends it by the size of the @$bind_aref array. It is most likely crashing due to the latter: so either the array has got extremely large, or the internal state of the array has got corrupted in some fashion.

What version of perl is this, and is it compiled as 32-bit or 64-bit? The commands perl -v and perl -V |grep ivsize should tell you these.

Dave.

Replies are listed 'Best First'.
Re^2: Crash in stack_grow() with SQL::Abstract
by ikegami (Patriarch) on Jun 03, 2025 at 14:35 UTC

    Tip: perl -V |grep ivsize can be replaced with perl -V:ivsize.

    The argument is an anchored regex, so you can also do stuff like perl -V:'install.*'.

Re^2: Crash in stack_grow() with SQL::Abstract
by Casey2255 (Initiate) on Jun 03, 2025 at 14:41 UTC
    Thank you for all the great info. For reference, these are the current versions we're running:
    • Perl version: 5.32.1
    • DBIx::Class version: 0.082841
    • SQL::Abstract version: 1.87
    And per the outputs of those commands:
    • Target: arm-linux-gnueabihf-thread-multi-64int
    • IVSize: 8
      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.

        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()
        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)