Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #108820
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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