[capi-sig] C/API error handling

[Campbell Barton]

Hi Joe, was thinking of messing with the memory allocator yes. maybe 
there are other areas also, but the memory allocator would be a good 
place to start.

This could be a compile time option for python, maybe a module thats 
only built in debug mode, or a seperate option.

---
import CAPIForceError
CAPIForceError.setmemfail(0.01)

...test the apis error stability...

---

So python could initialize etc without failing, and the test code would 
have to set the error probability before it runs a script that tests the 
api.


Joe Eagar wrote:
> One thing you could do is hack the python allocator to fail every once 
> in a while.  However, this is likely to cause problems within python 
> itself, along with problems with a python api codebase.
> 
> The allocator is in Objects/obmalloc.c in the python source, iirc.
> 
> Joe
> 
> Campbell Barton wrote:
>> In the Python C api is that your supposed to check every operation 
>> succeeds. - Append, a new list, a new float etc.
>>
>> This makes sense, since somebody could append to a list until the 
>> system is out of memory.. or whatever.
>>
>> The thing that bothers me is theres no good way to test the error cases.
>>
>> For example in Blender3D and PyGame (the only 2 C API's I'v looked at) 
>> - many checks for failed operations are missing. so its possible 
>> somebody could run out of ram and crash the API with python.
>>
>> for Blender3D or PyGame it probably dosnt matter a great deal, but in 
>> other cases, you'd want to make sure that doing crazy stuff within an 
>> exception (for example) wont crash the application.
>> Not just to look at the code and think it should work but actually run 
>> the error case.
>>
>> Is there any way to do this?
>>
>> I was thinking there could be a debug mode where python/C API 
>> functions like PyObject_New, PyList_Append etc randomly fail a 
>> percentage of the time.
>>
>> Then you could run unit tests in a debugger and any crashes could be 
>> traced.
>> This isnt an exact approach but if the unit tests run enough times you 
>> could be fairly sure its well tested (assuming the unit tests cover 
>> the API).
>>
>> Anyone tried this before or does something like this already exist?
>>
>>   
> 
> 


-- 
Campbell J Barton (ideasman42)