throwing exception when new fails

[Nathan Sidwell <nathan at acm dot org>]

Some time ago I filed a bug report about throwing when there's no memory
(http://www.cygnus.com/ml/egcs-bugs/1998-Sep/0229.html). The basic
problem is that this process invokes malloc (which doesn't have any
memory) -> boom!

Anyway, I've been figuring out how to fix this. I altered
__new_eh_context to have a static eh_context which it can use, should
malloc fail. Also I added a small buffer to eh_context, which __eh_alloc
and eh_free can use, should malloc fail. I've assumed that __eh_alloc
and eh_free are called in a stack-like manner (I had to alter
__cp_pop_exception, to do this). As __eh_alloc and __eh_free have become
more closely integrateed with __eh_context, I moved them to libgcc2
(from cp/exception.cc). This all works, and provides some degree of
safety in both single threaded and multithreaded applications.

Now the problem I've found is in frame.c. __throw calls 
__frame_state_for to obtain the function frame information. This ends up
generating an ordered list of the fde's (what's FDE stand for?), which
it then searches to locate the function information. This ordered list
is cached for futre use. *But*, guess what, frame_init calls malloc to
generate space for this list. I can find little documentation on what's
going on here. frame.c's pretty well commented, but omits the big
picture about what it's trying to acheive. From what I see modules can
register their functions with __register_frame_info or
__register_frame_info_table, and these get chained along. (I'm not sure
if this is also for DLL functions, I think not.) The first exception
thrown causes this list to be walked to create the ordered table.

Thus, I can fix things so that after the first exception, malloc dying
won't blow the exception mechanism away, but I can't see how to fix it
for the first one. Also, start_fde_sort, doesn't check malloc's failure
-- other parts of frame.c do check bogus info and abort if things are
awry.

Perhaps I should just punt it and if you want throw(bad_alloc) to work,
throw once per thread first (if that is acceptable, then I can simplify
my current fixes). Or perhaps we should allocate the space for the
ordered table during program start up. Suggestions?

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk