Il 20/07/2012 13:38, Daniel P. Berrange ha scritto: > There's two aspects to it. First we forbid use of malloc/free/realloc > in favour of an alternative set of APIs designed such that we can get > compile time errors when people don't check the result for NULL. > > > http://berrange.com/posts/2008/05/23/better-living-through-api-design-low-level-memory-allocation/ > > This has been very successful in ensuring code checks for OOM correctly. > Second there is a mode in our test suites where you can run under > simulated OOM - it runs once to count the total set of mallocs in the > test, and then re-run it 'n' times failing each malloc in turn and > verifying that we correctly report the OOM error condition.
Does it fail each malloc in turn, or does it fail each malloc "above X bytes" after the Y-th? Because the latter is what you actually get in practice, and it seriously hampers your recovery capabilities. Right now, we always use g_malloc and abort on failure, but we could replace it with g_try_malloc in specific large allocation cases, where large could even be not that large, for example around 64K. Paolo
