Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #108820

Re: setrecursionlimit

From Gregory Ewing <greg.ewing@canterbury.ac.nz>
Newsgroups comp.lang.python
Subject Re: setrecursionlimit
Date 2016-05-19 21:00 +1200
Message-ID <dq5dkkFnk99U1@mid.individual.net> (permalink)
References <573c941f$0$22141$c3e8da3$5496439d@news.astraweb.com> <d75fdf2c-fa98-4d6d-93ba-47a63c330e16@googlegroups.com> <nhi5a4$99a$1@dont-email.me> <573ca324$0$1604$c3e8da3$5496439d@news.astraweb.com>

Show all headers | View raw


Steven D'Aprano wrote:
> I don't really understand why the system can't track the current top of the
> stack and bottom of the heap, and if they're going to collide, halt the
> process.

That effectively *is* what it does.

The reason it manifests as a segfault is because of the way it
goes about detecting the heap/stack collision. It would be very
expensive to explicitly check for this every time something is
pushed or popped on the stack, so what OSes typically do instead
is reserve a buffer zone of unmapped memory between the stack
and the heap. If the stack overflows, you end up trying to
reference memory in the unmapped area, and a segfault results.

This is not foolproof -- if you allocate a *really* big stack
frame, you could leap right over the buffer zone and clobber
the heap. But it works well enough most of the time and
succeeds in stopping the program before it accidentally
launches the nuclear missiles.

Hardware support for stack bounds checkinbg would of course make
all this easier and more reliable, but the x86 architecture
doesn't provide anything like that, unfortunately.

-- 
Greg

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

setrecursionlimit Steven D'Aprano <steve@pearwood.info> - 2016-05-19 02:11 +1000
  Re: setrecursionlimit Ned Batchelder <ned@nedbatchelder.com> - 2016-05-18 09:19 -0700
    Re: setrecursionlimit Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-05-18 16:29 +0000
      Re: setrecursionlimit Steven D'Aprano <steve@pearwood.info> - 2016-05-19 03:15 +1000
        Re: setrecursionlimit Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-18 11:38 -0600
        Re: setrecursionlimit Chris Kaynor <ckaynor@zindagigames.com> - 2016-05-18 10:47 -0700
          Re: setrecursionlimit breamoreboy@gmail.com - 2016-05-18 14:43 -0700
            Re: setrecursionlimit Rustom Mody <rustompmody@gmail.com> - 2016-05-18 20:19 -0700
              Re: setrecursionlimit Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-19 21:04 +1200
        Re: setrecursionlimit Christian Gollwitzer <auriocus@gmx.de> - 2016-05-18 20:11 +0200
        Re: setrecursionlimit Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-19 21:00 +1200
    Re: setrecursionlimit Chris Kaynor <ckaynor@zindagigames.com> - 2016-05-18 09:56 -0700
    Re: setrecursionlimit Nobody <nobody@nowhere.invalid> - 2016-05-19 11:28 +0100
  Re: setrecursionlimit Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-05-19 10:27 +0100

csiph-web