[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: guarantees of exception safety in Lua
- From: "Sam Roberts" <vieuxtech@...>
- Date: Tue, 28 Oct 2008 13:04:57 -0700
On Tue, Oct 28, 2008 at 12:19 PM, David Given <dg@cowlark.com> wrote:
> In a desperate attempt to bring things back on topic, I'll point out
To help you out in this attempt... :-)
I've spent a bunch of time testing libraries written for embedded
systems that were expected to deal with malloc failure (by returning
an error and releasing all memory,
as opposed to segfaulting and mem leaking).
What we did was wrap our unit tests in a loop that basically said:
e = ENOMEM;
for(failon=1; e == ENOMEN; failon++)
{
e = run_unit_test()
assert(allocated_memory == 0);
assert(e == ENOMEM || e == 0);
}
failon would force the ith call of malloc to fail. Interestingly,
Symbian is the only dev environment I've seen that seems to recognize
the utitility of this, and it has a mode in which you can seed its
allocation library, and the seed will be used to "randomly" fail
allocations. An excellent idea.
Anyhow, all the code we tested segfaulted or leaked memory, and it had
been written knowing that it would be tested like this. All the code
"looked" like it did the right things - checked malloc returns,
cleaned up prior allocation when previous ones had failed, etc., but
always something would have been forgotten.
I've since come to the conclusion that malloc() NEVER fails on modern
operating systems, so the code theoretically written to recover from
failure never runs, and code that has never been run is not going to
work when it is run.
I used to think programming with an xmalloc() that just exited on
allocation failure was lazy. No longer. I know think that every
programmer who thinks their code survives malloc failure (but haven't
acutally tested it) is wrong. And I've proved it repeatedly on code
who's authors thought they were the exception.
Anyhow, what exactly would a lua program that caught an out of memory
exception do? There isn't enough memory to run lua, so how is any lua
code supposed to recover? Cleanup and get out are pretty much your
only options.
It would be trivial to do this kind of testing with lua, because you
can pass in your own malloc implementation, and a destroyed lua_State
should clean up all memory allocated during its lifetime. I might hack
up a lua exe some time to do this, it'd be interesting!
Cheers,
Sam