andyvand / gmpy

Automatically exported from code.google.com/p/gmpy
GNU Lesser General Public License v3.0
0 stars 0 forks source link

segfault in mpz when rediculously huge numbers are used #17

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. http://dpaste.com/87279/ <- executing that script
2.
3.

What is the expected output? What do you see instead?
I expect the program to calculate the large number, it doesn't

What version of the product are you using? On what operating system?
Svn checkout from about four hours ago x64 ubuntu

Original issue reported on code.google.com by Samphip...@googlemail.com on 28 Oct 2008 at 1:46

GoogleCodeExporter commented 9 years ago
The output I get from the sample code is a trace dump with:
  RuntimeError: maximum recursion depth exceeded in cmp
which seems exactly right to me -- i.e., I don't see a segfault (with my mac's 
system-installed Python) 
because it does use a very large stack and so can actually support ridiculously 
high recursion-limit (and this 
code exceeds even that).  Segmentation faults are typical of runaway recursion 
when you've set the limit 
higher than your version of Python can actually support, e.g.:

import sys
sys.setrecursionlimit(1500000)
def r(): return r()
r()
DOES give a segmentation fault.

Unless you can reproduce the problem with a non-recursion case, I'll have to 
close this as unrelated to gmpy.

Original comment by alea...@gmail.com on 28 Oct 2008 at 2:19

GoogleCodeExporter commented 9 years ago
gmpy 1.04 fixed a memory allocation bug that did limit the size of the string
representation. However, your example would still exceed the memory limits of 
most
computers. There is nothing else that can be done from the gmpy side.

Original comment by casevh on 8 Apr 2009 at 5:19