in reply to Perl Deep Recursion locks up modern linuxes?

Perl's execution stack is malloced() from the heap rather than using the C stack, so infinite recursion just means perl keeps mallocing memory. My general experience with runaway processes on Linux is that the machine grinds to a complete halt (with not even the cursor moving) for several minutes until the process dies or is killed, then things slowly come back to normal (as swapped out memory is brought back in).

If it's just a malloc() problem, then something like

perl -e'push @a, 1 while 1'
should kill the machine just as easily,

Dave.

Replies are listed 'Best First'.
Re^2: Perl Deep Recursion locks up modern linuxes?
by eyepopslikeamosquito (Archbishop) on Oct 09, 2016 at 20:54 UTC

    Back when Re: Not able to release memory (malloc implementation) was written, glibc 2.x based Linux systems used ptmalloc, which is based on Doug Lea's malloc. This version of malloc uses mmap(2), rather than sbrk(2), when the chunk of memory requested is larger than some threshold value (typically 128K). So, an interesting test would be to adjust Dave's little memory eater program above to repeatedly push "large" strings (greater than 128K, say) and see if that makes any difference to machine lockup behaviour.

    Further things you might try:

    • Take Perl out of the equation. Write a small C program that just keeps on malloc'ing strings of various sizes and see if running such a program locks up the whole machine.
    • Build a custom perl with an instrumented/different version of malloc to help you debug what is going on.
    • Check version history of the Linux/glibc C sources to try to find the change that triggered this new "machine lockup" behavior.

Re^2: Perl Deep Recursion locks up modern linuxes?
by vsespb (Chaplain) on Oct 09, 2016 at 17:31 UTC
    Yes, your code example freezes machine same way. So you experience this all the time? My experience that it never freeze such way before (I used Ubuntu 12, 10, 9, 8 last 10 years after switching from Windows).
      So you experience this all the time?
      It's been my general experience with Linux for many years. In olden times it used to be the OOM killer killing off random processes that made the machine unusable - I don't know whether they've improved it.

      The usual scanario is that I'm investigating a leak in the perl core, or have just introduced one (I'm a core developer), and if i don't spot that I have a problem, I find the UI going very slowly, at which point I madly try to bring the cursor into the right terminal window and ^C repeatedly. About half the time I end up having to reboot the machine.

      I use Fedora.

      Dave.

        ulimit is your friend...

        On Linux, there is also a Magic SysRq key (usually f) allowing one to invoke the OOM killer on demand.