GCC 2.95: exceptions + large prog + small stack == core

[Jim Rauser]

We have a large program (2.7 MLOC, 18 MB text segment) which makes
heavy use of C++ exception handling, templates, and threads.
In threads other than the main one, we have reduced the stack size
from the default (1MB, I think) to 256K.  This is more than adequate
for the application code.  When compiled with GCC, and the first
exception thrown in the program is in a thread with a reduced stack
size, a core dump is produced.

I've traced the problem to code in the function split_fde() in
gcc/frame.c in the 2.95 distribution.  But: first the vital
statistics:

caligula@/home/rauser> gcc -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95/specs
gcc version 2.95 19990728 (release)

caligula@/home/rauser> uname -a
SunOS caligula 5.6 Generic_10581-13 sun4u sparc SUNW,Ultra-Enterprise

The machine has 6 processors and 3GB RAM.

No special configuration options were used, and no modifications
have been made to the GCC source code.

I can't send a minimal example, because the problem is directly
related to the size of the program.  The relevant code is the
function split_fde in gcc/frame.c:

/* Split LINEAR into a linear sequence with low values and an erratic
   sequence with high values, put the linear one (of longest possible
   length) into LINEAR and the erratic one into ERRATIC. This is O(N).
*/
static inline void
fde_split (fde_vector *linear, fde_vector *erratic)
{
  size_t count = linear->count;
  size_t linear_max = (size_t) -1;
  size_t previous_max[count];
  size_t i, j;

  [code snipped...]
}

The problem is that linear->count has a value of ca. 70,000.
I believe that this value is correct, or at the very least has
not been corrupted during the process of sorting the fde's,
because the function count_fdes(), when called for the first time
from frame_init(), also returns a value over 70,000.

This causes the array previous_max, allocated on the stack, to
have a size of over 300k (!).  Since the thread stacks are
reduced to 256k, the result is obvious.  I've worked around the
problem by increasing the thread stack sizes, but that's a waste
of good address space.  Is there a reason that malloc() was not
used here, as it was in start_fde_sort() when the fde_accumulator
was initialized?

Thanks for your help,
Jim
-- 
------------------------------------------------------------------------
Jim Rauser                                mailto:rauser@mac-info-link.de
Mac-Info-Link GmbH
Max-Planck-Str. 39a                                 Tel: 02234/950 36 16
D-50858 Köln                                         Fax: 02234/27 19 17