http://prt-web.us.oracle.com/archive/2011/02/2011-02-08-221256.kvn.7014998_hs20/crashes/solaris_x64-fastdebug-c2-GCBasher_G1.hs_err_pid24348.log

The decode symbols on 64 bit are very wrong looking:

---------------  T H R E A D  ---------------

Current thread (0x000000000a1a4000):  ConcurrentGCThread [stack: 0xfffffd7fea6ff000,0xfffffd7fea7ff000] [id=30]

Stack: [0xfffffd7fea6ff000,0xfffffd7fea7ff000],  sp=0xfffffd7fea7fd180,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x168a0b8]  JVM_handle_solaris_signal+0x35e668
V  [libjvm.so+0x168b2aa]  JVM_handle_solaris_signal+0x35f85a
V  [libjvm.so+0xa7f077]  void report_fatal(const char*,int,const char*)+0x67
V  [libjvm.so+0x130f770]  JVM_FindSignal+0x3de4b0
V  [libjvm.so+0x1310943]  JVM_FindSignal+0x3df683
V  [libjvm.so+0x5d927d]  _PROCEDURE_LINKAGE_TABLE_+0x1a92f5
V  [libjvm.so+0x14bb380]  JVM_handle_solaris_signal+0x18f930
V  [libjvm.so+0xc2906c]  AsyncGetCallTrace+0xeb4dc
V  [libjvm.so+0xc2a119]  AsyncGetCallTrace+0xec589
V  [libjvm.so+0x9dbb29]  void ConcurrentMark::completeCleanup()+0x299
V  [libjvm.so+0xa3c91a]  void ConcurrentMarkThread::run()+0xffa
V  [libjvm.so+0x131640a]  JVM_FindSignal+0x3e514a
C  [libc.so.1+0xd504b]  _thr_slot_offset+0x31b
C  [libc.so.1+0xd5280]  _thr_slot_offset+0x550

This is what the regular hs_err says for it:

Stack: [0xfffffd7fea6ff000,0xfffffd7fea7ff000],  sp=0xfffffd7fea7fd180,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x168a0b8]  JVM_handle_solaris_signal+0x35e668;;  __1cHVMErrorGreport6MpnMoutputStream__v_+0x9b8
V  [libjvm.so+0x168b2aa]  JVM_handle_solaris_signal+0x35f85a;;  __1cHVMErrorOreport_and_die6M_v_+0x4ca
V  [libjvm.so+0xa7f077]  void report_fatal(const char*,int,const char*)+0x67;;  __1cMreport_fatal6Fpkci1_v_+0x67
V  [libjvm.so+0x130f770]  JVM_FindSignal+0x3de4b0;;  __1cMverify_block6Fpv_v_+0x2c0
V  [libjvm.so+0x1310943]  JVM_FindSignal+0x3df683;;  __1cCosEfree6Fpv_v_+0x63
V  [libjvm.so+0x5d927d]  _PROCEDURE_LINKAGE_TABLE_+0x1a92f5;;  __1cICHeapObj2k6Fpv_v_+0x3d
V  [libjvm.so+0x14bb380]  JVM_handle_solaris_signal+0x18f930;;  __1cJSparsePRTFclear6M_v_+0x100
V  [libjvm.so+0xc2906c]  AsyncGetCallTrace+0xeb4dc;;  __1cROtherRegionsTableFclear6M_v_+0xcc
V  [libjvm.so+0xc2a119]  AsyncGetCallTrace+0xec589;;  __1cQHeapRegionRemSetFclear6M_v_+0x19
V  [libjvm.so+0x9dbb29]  void ConcurrentMark::completeCleanup()+0x299;;  __1cOConcurrentMarkPcompleteCleanup6M_v_+0x299
V  [libjvm.so+0xa3c91a]  void ConcurrentMarkThread::run()+0xffa;;  __1cUConcurrentMarkThreadDrun6M_v_+0xffa
V  [libjvm.so+0x131640a]  JVM_FindSignal+0x3e514a;;  java_start+0x25a
C  [libc.so.1+0xd504b]  _thr_slot_offset+0x31b;;  _thr_setup+0x5b
C  [libc.so.1+0xd5280]  _thr_slot_offset+0x550;;  _lwp_start+0x0

I think the 64 bit build is using the 32 bit elf definitions:

(dbx) whatis -t Sym 
typedef struct {
    Elf32_Word st_name;
    Elf32_Addr st_value;
    Elf32_Word st_size;
    unsigned char st_info;
    unsigned char st_other;
    Elf32_Half st_shndx;
} Sym;

so when we're calling dladdr1 we're interpreting the results incorrectly.  All the ElfFile stuff is probably suffering from the same problem.  I would have expected the symbols to be mapped automatically to the 64 bit version but it looks like this is only done if _ELF64 is defined.  I can't see that defined anywhere in /usr/include, so maybe it's our responsibility to define it?