You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Li Ping Zhang (JIRA)" <ji...@apache.org> on 2012/11/28 09:20:58 UTC

[jira] [Assigned] (HBASE-7127) some UT failed with core dump of IBM JDK SR10

     [ https://issues.apache.org/jira/browse/HBASE-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Li Ping Zhang reassigned HBASE-7127:
------------------------------------

    Assignee: Li Ping Zhang
    
> 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
>            Assignee: 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