JDBC application crashes with Sigsegv In Gctaskthread (Doc ID 1178043.1)

Last updated on JUNE 21, 2016

Applies to:

Oracle TimesTen In-Memory Database - Version and later
Information in this document applies to any platform.

***Checked for relevance on Jan 14, 2015***


=== ODM Issue Clarification ===

JDBC application connecting to TimesTen core dumps with SIGSEGV in GCTaskThread

Stack trace looks like this:

ffffffff7e36b488 __1cSPSPromotionManagerWcopy_to_survivor_space6MpnHoopDesc_b_2_ (1043f38e0, fffffffdc4dae238, 1, ffffffff4a370838, 120, 0) + 90
ffffffff7e36c4b0 __1cKPSScavengebAcopy_and_push_safe_barrier4CpnHoopDesc__6FpnSPSPromotionManager_pTA_v_ (1043f38e0, fffffffe391815b8, fffffffdc4dae238, 381bc8, ffffffff7e6ee000, 1857f) + 80
ffffffff7e36af84 __1cSPSPromotionManagerSdrain_stacks_depth6Mb_v_ (1043f39f0, 1043f3988, 1043f38e0, ffffffff7e6ee000, 1043f3990, 1043f3988) + 8e4
ffffffff7de04688 __1cSCardTableExtensionbAscavenge_contents_parallel6MpnQObjectStartArray_pnMMutableSpace_pnIHeapWord_pnSPSPromotionManager_I_v_ (38, 10011ea30, ffffffff7e73e3c0, fffffffe39182828, 1043f38e0, ffffffffffffffff) + a58
ffffffff7de03b9c __1cTOldToYoungRootsTaskFdo_it6MpnNGCTaskManager_I_v_ (10017d6b0, 120, 12, 8ea4ac, ffffffff7e6ee000, 0) + 4c
ffffffff7de8d8e0 __1cMGCTaskThreadDrun6M_v_ (10014c000, 10013aee0, ffffffff7de050a8, ffffffff7e758018, 10017d6b0, ffffffff7e55cb93) + 1e8
ffffffff7e32de00 java_start (10014c000, 3c78, ffffffff7e755394, ffffffff7e6ee000, ffffffff7e54c42f, ffffffff7e76cd14) + 238
ffffffff7edd5fe0 _lwp_start (0, 0, 0, 0, 0, 0)

Stack: [0x73e04000,0x73e85000], sp=0x73e83e50, free space=1ff73e837f4k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x53ed6e];; PSPromotionManager::copy_to_survivor_space(oopDesc*, bool)+0x2e
V [libjvm.so+0x540fe1];; PSPromotionManager::drain_stacks_depth(bool)+0x601
V [libjvm.so+0x1e1011];; CardTableExtension::scavenge_contents_parallel(ObjectStartArray*, MutableSpace*, HeapWord*, PSPromotionManager*, unsigned int)+0x881
V [libjvm.so+0x5436ca];; OldToYoungRootsTask::do_it(GCTaskManager*, unsigned int)+0x3a
V [libjvm.so+0x30cea5];; GCTaskThread::run()+0xd5
V [libjvm.so+0x4f86b9];; java_start(Thread*)+0xf9
C [libpthread.so.0+0x61b5]

According to our Sun contacts, a characteristic of the JVM bug's heap corruption is that the hs err files showed for the heap a high use of eden space,

Below is from hs_err_pid****.log (**** is just a placeholder for the pid number that crashed):
PSYoungGen total 1526976K, used 1505255K [0xfffffffef0000000, 0xffffffff50000000, 0xffffffff70000000)
eden space 1481024K, 100% used [0xfffffffef0000000,0xffffffff4a650000,0xffffffff4a650000)
from space 45952K, 52% used [0xffffffff4d320000,0xffffffff4eac9e00,0xffffffff50000000)
to space 45888K, 97% used [0xffffffff4a650000,0xffffffff4d1d59f0,0xffffffff4d320000)



This is triggered by a bug in  Sun JVM garbage collector code in JRE 1.6.0, fixed in 1.6u18-rev(b09) or later.


Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms