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/08 04:48:12 UTC

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

Li Ping Zhang created HBASE-7127:
------------------------------------

             Summary: 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: Bug
    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

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

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492940#comment-13492940 ] 

stack commented on HBASE-7127:
------------------------------

[~michelle] As it says in prereqs, we expect oracle jvm until someone does the work to make us run on other jvms.  Yes, we use Unsafe.

What is your objective Li?  Can we help out?
                
> 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: Bug
>    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

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

Posted by "Li Ping Zhang (JIRA)" <ji...@apache.org>.
     [ 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

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

Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
     [ 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