Re: setrecursionlimit

On Wed, 18 May 2016 09:19:25 -0700, Ned Batchelder wrote: > Is there a way to know how large the C stack can grow, Yes. For the main thread, getrlimit(RLIMIT_STACK). For other threads, pthread_attr_getstacksize(). > and how much it will grow for each Python function call? No. Depending upon

Re: setrecursionlimit

t; Indeed, if you set the recursion limit too high, you can smash the memory > heap and get a segfault. How exactly does that work? > > Why doesn't setrecursionlimit() raise an exception when you try to set it > too high? For example: > > sys.setrecursionlimit(20) > >

Re: setrecursionlimit

Rustom Mody wrote: Both the mess in catching numeric overflow as well as stackoverflow looks like its C's fault. I consider it as the fault of currently fashionable stock hardware The sad thing about C is that it doesn't even help you detect integer overflow in *software*. Every machine I've

Re: setrecursionlimit

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

Re: setrecursionlimit

On Thursday, May 19, 2016 at 3:13:44 AM UTC+5:30, bream wrote: > On Wednesday, May 18, 2016 at 6:47:42 PM UTC+1, Chris Kaynor wrote: > > On Wed, May 18, 2016 at 10:15 AM, Steven D'Aprano wrote: > > > > > I don't really understand why the system can't track the current top of > > > the > > >

Re: setrecursionlimit

Am 18.05.16 um 19:15 schrieb Steven D'Aprano: Not being a C programmer, I don't really understand this. The idea I have in mind is a model of program memory I learned[1] way back in the 80s. I don't know if it's still valid. Your application has a bunch of memory available, which broadly

Re: setrecursionlimit

On Wed, May 18, 2016 at 10:15 AM, 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 would still be kinda awful, in a sudden "your

Re: setrecursionlimit

On Wed, May 18, 2016 at 11:15 AM, 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 would still be kinda awful, in a sudden "your

Re: setrecursionlimit

On Thu, 19 May 2016 02:29 am, Rob Gaddi wrote: > Ned Batchelder wrote: >> Is there a way to know how large the C stack can grow, and how much it >> will grow for each Python function call? That sounds complicated to get >> right. >> >> --Ned. > > It's probably trivial to look at a number and

Re: setrecursionlimit

On Wed, May 18, 2016 at 9:19 AM, Ned Batchelder wrote: > I believe the issue here is that Python recursion results in the C stack > growing. Each Python function call creates a number of C function calls, > which grows the C stack. The crash you see is the C stack

Re: setrecursionlimit

> https://docs.python.org/3/library/sys.html#sys.setrecursionlimit >> >> Indeed, if you set the recursion limit too high, you can smash the memory >> heap and get a segfault. How exactly does that work? >> >> Why doesn't setrecursionlimit() raise an exception when you try

Re: setrecursionlimit

Indeed, if you set the recursion limit too high, you can smash the memory > heap and get a segfault. How exactly does that work? > > Why doesn't setrecursionlimit() raise an exception when you try to set it > too high? For example: > > sys.setrecursionlimit(20) > &g

setrecursionlimit

doesn't setrecursionlimit() raise an exception when you try to set it too high? For example: sys.setrecursionlimit(20) succeeds on my system, even though that's a ludicrously high number. (It is more than half the number of bytes of memory my computer has.) So why can't Python tell if I'm