Greg Hudson <ghudson@mit.edu> writes:
> So, we have a fancy error-handling framework which involves
> potentially allocating a linked list as we crawl up the stack. At the
> same time, we have a fancy memory management framework which involves
> potentially creating sub-pools to do temporary allocations in and
> destroying them when we finish our work.
>
> I am concerned by the potential for conflict here. In many cases, you
> may not have a pool available to you which will live as long as the
> error has to live. In other cases, you may only have a pool available
> which lasts much longer than the error has to live, which could lead
> to memory leaks. And in general, you can't even identify these cases,
> much less address them.
>
> Has anyone thought about this issue?
Yeah, weird, this exact issue came up a while back -- I thought at the
time that we came up with a solution, but looking at the code now, I
don't see that any solution was implemented. The problem you describe
is still there.
Doh, I must not have been paying enough attention to the thread back
then, sorry.
Possible solution:
What if the error code always allocated using malloc(), instead of
pool stuff? This isn't so awful, after all, Expat is already
allocating in its own universe. Since our errors are supposed to live
independently of subpool lifetimes, it would make sense for them to
allocate independently of pools too.
Thoughts?
Received on Sat Oct 21 14:36:08 2006