Having a look at the "crashers" in Lib/test/crashers it seems to me that they fall into four groups. 1. Unsafe gc functions like getreferrers() 2. Stack overflows. 3. "Normal" bugs that can be fixed on a case-by-case basis (like borrowed_ref_1.py and borrowed_ref_2.py) 4. Things that don't crash CPython anymore and should be moved. 1. can be dealt with by removing the offending function(s), 3. by fixing the problem directly. 4. no need to fix, just move :) So, how to handle stack overflows (of the C stack)? To prevent a stack overflow an exception must be raised before the VM runs out C stack. To do this we need 2 pieces of info: a) How much stack we've used b) How much stack is available. (a) can be easily, if not strictly portably, determined by taking the address of a local variable. (b) is tougher and is almost certainly OS dependent, but a conservative estimate is easy to do. A different approach is to separate the Python stack from the C stack, like stackless. This is a much more elegant approach, but is also a *lot* more work. I think it is a reasonable aim for 3.3 that Lib/test/crashers should be empty. Cheers, Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4