Customer's weblogic based application crashes with the following error
using debug jdk 1.3.1_03, in native awt font code:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x844849ec
Function name=__1cUCompositeGlyphMapperTgetMissingGlyphCode6kM_i_
Library=/apps/opt/jdk131/jre/lib/sparc/libfontmanager_g.so
** complete error and java stack is in the attachment:
javag_core_othinfo.gz

The dbx stack snippet (from debug jdk 1.3.1_03) is as follows:
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [11] hsGGlyphStrike::CountGlyphs(0x0, 0x51ad700, 0x8f07e490, 0x0, 0x1, 0x5667e80),
at 0x844849ec
  [12] Strike::compositeStrikeForSlot(0x5887c48, 0x0, 0x13950, 0x8448167c, 0xff249ad8,
0x560da50), at 0x844839ac
  [13] Strike::GetLineHeight(0x5887c48, 0x8f07e5f4, 0x8f07e5ec, 0x8f07e5e4, 0x8f07e5dc,
0x8f07e5d4), at 0x84482584
  [14] Java_sun_awt_font_NativeFontWrapper_getFontMetrics(0x992ee0, 0x8f07e698, 0x8f07e71c,
0x8f07e718, 0x0, 0x0), at 0x84460c64
** complete dbx stack and the core file from Sun4u E4500/E5500 is in attached file:
javag_core_othinfo.gz

We have seen similar stack traces as above using non-debug jvm and the info is
saved in the attached file: java_core_othinfo.gz (core is from Sun4u E4500/E5500)
This part of the test run also contains truss output.

Unfortunately, this problem is only reproducible (at will) on their production
environment and not on their staging/qa/dev environments. Unfortunately there
is no test case which reproduces exact same problem.

We have collected other info to rule out a font corruption problem, etc,
saved this info as part of attached file showrev_pkgchk_othrinfo.gz:
- captured truss output (as stated above)
- showrev -p output
Customer is using pretty recent version of Xserver patch 108652-53
(current rev is at -55)
- Package check info of all font packages on the system
- Customer does not have LANG env variable set, neither does he have
any LC_* variables set (not sure about the impact of this)
- Unfortunatley we couldn't get "xset -q" output (but they claim not to
change the default fontpath as such)