[ https://issues.apache.org/jira/browse/HBASE-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Purtell updated HBASE-7127: ---------------------------------- Issue Type: Sub-task (was: Bug) Parent: HBASE-7149 > some UT failed with core dump of IBM JDK SR10 > --------------------------------------------- > > Key: HBASE-7127 > URL: https://issues.apache.org/jira/browse/HBASE-7127 > Project: HBase > Issue Type: Sub-task > Affects Versions: 0.92.0 > Environment: RHEL 5.3, IBM JDK SR 10. > Reporter: Li Ping Zhang > > I used IBM JDK 6, SR10 to individually run several unit tests, like `mvn > test -Dtest=org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat`, then > there are JVM crush issues(detail log is as following) existed. There may be > programming issues like passing a null or no-defined parameters into > sun_misc_Unsafe_getLong__Ljava_lang_Object(), and I looked into some class, > it really calls Unsafe.getLong(), which still need to be fixed by deeply > debugging every unit test codes' passing values case by case. > ------------------------------------------------------------------------- > Here is the JVM crush log: > Unhandled exception > Type=Segmentation error vmState=0x00000000 > J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 > Sig > nal_Code=00000080 > Handler1=00002AAAAACE84C0 Handler2=00002AAAAB0787B0 > InaccessibleAddress=00000000 > 00000000 > RDI=1000000016000000 RSI=000000000DBEEB42 RAX=0000000000000022 > RBX=000000000DC8A > AA0 > RCX=00002AAB0C0D7910 RDX=1000000016000000 R8=1000000016000000 > R9=0000000040DA915 > 0 > R10=000000000D7C61A8 R11=00000000FFFFFFFF R12=0000000000000000 > R13=0000000000000 > 022 > R14=00002AAAAAE4D160 R15=00002AAAAABCDF00 > RIP=00002AAAAFEBF5A9 GS=0000 FS=0000 RSP=00002AAB0C0D7838 > EFlags=0000000000210202 CS=0033 RBP=000000000D78FF00 ERR=0000000000000000 > TRAPNO=000000000000000D OLDMASK=0000000000000000 CR2=0000000000000000 > xmm0 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm1 000000003f400000 (f: 1061158912.000000, d: 5.242822e-315) > xmm2 000000003f733333 (f: 1064514368.000000, d: 5.259400e-315) > xmm3 000000004008ce33 (f: 1074318848.000000, d: 5.307841e-315) > xmm4 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm5 00002aaaafad8300 (f: 2947384064.000000, d: 2.317789e-310) > xmm6 00002aaaaae4d160 (f: 2867122432.000000, d: 2.317785e-310) > xmm7 000000000d771858 (f: 225908832.000000, d: 1.116138e-315) > xmm8 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm9 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm10 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm11 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm12 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm13 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm14 0000000000000000 (f: 0.000000, d: 0.000000e+00) > xmm15 0000000000000000 (f: 0.000000, d: 0.000000e+00) > Module=/root/zhangliping/sdk/jre/lib/amd64/default/libjclscar_24.so > Module_base_address=00002AAAAFE72000 > Symbol=sun_misc_Unsafe_getLong__Ljava_lang_ > Object_2J > Symbol_address=00002AAAAFEBF568 > Target=2_40_20110722_087476 (Linux 2.6.18-128.el5) > CPU=amd64 (8 logical CPUs) (0x7da32a000 RAM) > ----------- Stack Backtrace ----------- > sun_misc_Unsafe_getLong__Ljava_lang_Object_2J+0x41 (0x00002AAAAFEBF5A9 > [libjclsc > ar_24.so+0x4d5a9]) > --------------------------------------- > JVMDUMP006I Processing dump event "gpf", detail "" - please wait. > JVMDUMP032I JVM requested System dump using > '/root/zhangliping/Hbase9.20.2/core. > 20111125.085237.3665.0001.dmp' in response to an event > JVMDUMP010I System dump written to > /root/zhangliping/Hbase9.20.2/core.20111125.0 > 85237.3665.0001.dmp > .... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira