throwing bad_alloc can blow up

[Nathan Sidwell]

Hi,
following my poking around at exception handling, I've found that
exception handling can blow up, if malloc fails. Since exceptions are
used to indicate malloc has failed, this is a bug. I guess the designers
of the exception handling system are probably aware of this design
problem, but there's nothing about it in the last three months on
egcs-bugs. I've attached a test case (.cc, and .ii files). This test
case redefines malloc with a simple allocator which can be turned off to
simulate malloc failing.

Here's the session log
--begin log
nathan@laie:461>uname -a
SunOS laie 5.5.1 Generic sun4u sparc SUNW,Ultra-1

nathan@laie:462>g++ -v -g -c exceptmalloc.ii
Reading specs from
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/specs
gcc version egcs-2.91.55 19980824 (gcc2 ss-980609 experimental)

/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/cc1plus
exceptmalloc.ii -quiet -g -Woverloaded-virtual -Wall -Wpointer-arith
-Wwrite-strings -ansi -version -felide-constructors -fnonnull-objects -o
/var/tmp/ccz24yYy.s
GNU C++ version egcs-2.91.55 19980824 (gcc2 ss-980609 experimental)
(sparc-sun-solaris2.5.1) compiled by GNU C version egcs-2.91.57 19980901
(egcs-1.1 release).

/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/as
-V -Qy -s -o exceptmalloc.o /var/tmp/ccz24yYy.s
GNU assembler version 2.8.1 (sparc-sun-solaris2.5.1), using BFD version
2.8.1

nathan@laie:463>g++ -v -g -o exceptmalloc exceptmalloc.o
Reading specs from
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/specs
gcc version egcs-2.91.55 19980824 (gcc2 ss-980609 experimental)

/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/collect2
-V -Y P,/usr/ccs/lib:/usr/lib -Qy -o exceptmalloc
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/crt1.o
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/crti.o
/usr/ccs/lib/values-Xc.o
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/crtbegin.o
-L/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55
-L/home/staff/nathan/solaris/local/SunOS_5/sparc-sun-solaris2.5.1/lib
-L/usr/ccs/bin -L/usr/ccs/lib
-L/home/staff/nathan/solaris/local/SunOS_5/lib exceptmalloc.o -lstdc++
-lm -lgcc -lc -lgcc
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/crtend.o
/home/staff/nathan/solaris/local/SunOS_5/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.55/crtn.o
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) -
versioning)

nathan@laie:464>./exceptmalloc 
inited
thrown once
zsh: 5716 IOT instruction (core dumped)  ./exceptmalloc

--end log
I've altered __eh_alloc and __eh_free (cp/exception.cc) to fall back on
a small static arena, if malloc fails. This has a number of shortcomings
at the moment (hence I'm not submitting it).
1)it requires __eh_alloc and __eh_free to be called in a stack-like
manner. This looks safe, modulo the next two difficulties.
2)it is not thread safe -- that would require separate arenas for each
thread.
3)it still blows up if malloc fails on the first thrown exception, but
not subsequent ones. This is because new_eh_context calls malloc on its
first go.

I think the correct solution is to ensure that each thread has a valid
eh_context during intialization (this is one place where lazy
initialization shoots you!). The context should contain the malloc
arena, so that solution 1 can be made thread safe.

I'm quite happy to have continue along these lines, unless someone tells
me not to.

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