GCJ 3.4.3 and 3.3 classloading problem

Hello everyone:

We use and maintain our own "exotic" ports of gcj 3.3 and 3.4.3 for
arm-wince-pe (Windows CE 5).  For some years we have been struggling
with a classloading problem that has recently become chronic.  As a
disclaimer, I first want to say that we have carefully thought through
which version of gcj we should port and use.  We went with 3.3 and
more recently 3.4.3 for primarily one reason:  libgcj in the 4 series
is prohibitively large for the embedded applications we have to field.
 So we are currently using 3.4.3 and binutils-2.17.50, and we are
sticking with that.  Please try not to dismiss this inquiry because
we're using an "older version".

The application exhibiting the classloading trouble is a port of the
Jetty application server to arm-wince-pe-gcj.  Jetty and most of the
infrastructure it uses (e.g. Spring, Velocity) are gcj-compiled (to
.o) and statically linked, but the webapp application code consists
.class files that are classloaded by gcj from a .war file by Jetty.

SOME of the time everything works, and there is no issue.  But
sometimes segmentation faults (C0000005) and alignment faults occur
during classloading.  The faults usually occur somewhere in string
processing, typically in java::lang::String::getChars.  Oddly, the
occurrence of these faults seems to depend on the particular details
of a given Jetty image link and the sizes of the linked object files.
For example, a 2 line change to one of the statically linked modules
can make a "working version" of our Jetty cease to work once the
modified Java sources are recompiled/relinked.

I have never seen anything like this, and have not seen anything so
baffling in quite a while.  I am not even sure where to start.
Otherwise, our port of gcj 3.4.3 to arm-wince-pe is working perfectly.
 PERFECTLY.

We are in a position where I have to fix this at any cost.  If I have
to climb Mount Everest, I will do that.  Any ideas on where to start
or what we could look at would be greatly appreciated.

Thanks in advance!
Craig Vanderborgh
Voxware Incorporated