[mips-gnu-discuss] Pre-built CodeSourcery C++ compilers segfault (ICE)

["Nigel Hathaway" <Nigel.Hathaway@xxxxxxxxxxxxx>]

This problem is also reported here:

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/563033


The bug is against 10.04 beta2 using either the 32-bit PAE kernel or the
64-bit kernel, and falls into the non-trivial and obscure category.

CodeSourcery provide a range of pre-built embedded gcc cross-compilers
for use on any Linux system with a compatible glibc. These compilers run
fine on our old Centos machines, and also on Ubuntu 9.10.

They also run fine on 10.04 beta2 in a VirtualBox VM with only 1Gb of
RAM. In addition, the same code compiles without issue using the
platform's native compiler.

However, I have installed both the 64-bit kernel and the 32-bit PAE
kernel for 10.04 beta2 and we are getting segfaults in what appears to
be glibc's memory allocation, though I'm not certain.

I have run the compiler under strace, and I have found that the segfault
occurs immediately after an anonymous private mmap operation. I am not
an expert on the way memory allocation is done at low-level, but I have
observed from previous strace output that memory allocation consists of
anonoymous private mmap's followed by brk calls. In the case where we
get the segfault, it calls the mmap but segfaults before it gets to the
brk.
Furthermore, we only get this when compiling complex C++ files with
heavy STL usage. Simple C++ or C files do not exhibit the problem. The
problem occurs during the parsing of the header files, typically a
standard STL header file. The problem may be circumvented by altering
the order of the #includes in the source files causing the segfault
(reported via compiler ICE). A typical include set has local C++ header
files, local "extern C" header files and standard STL header files, in
that order. Putting the STL header files first is what can stop the
segfault from happening.
You will appreciate that we have legacy code to maintain, and we can't
switch to newer compilers or make modifications to the source code in
question. Nor can we re-compile the compilers as CodeSourcery's support
depends on the use of their binaries.

Our build machine is a Dell PowerEdge R710 with 2 quad core processors
and 16GB of memory. We have Ubuntu server installed, including the ipmi
drivers. I have run memtest86+ overnight and have also run Dell's
hardware diagnostics, and there are no hardware faults. We have now
installed 9.10 on this machine and everything works perfectly.

The CodeSourcery embedded cross-compilers we are using are:

arm-2006q3-27-arm-none-linux-gnueabi-i686-pc-linux-gnu
arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu
mips-4.3-154-mips-linux-gnu-i686-pc-linux-gnu

The ARM and MIPS compilers have the same problem, but they fall over
compiling different C++ files.