Bug 952673
| Summary: | gcc-4.8.0 libgcj regression on 32bit Power architecture | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Phil Knirsch <pknirsch> | ||||||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 19 | CC: | aph, bbaude, flanagan, gustavold, jakub, karsten, law, masao-takahashi, rvokal | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | ppc | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2015-02-17 14:59:39 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 920769 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Phil Knirsch
2013-04-16 12:17:59 UTC
We also tried to change the lockig behavior with a simple patch like so but didn't yield a fix either:
--- libjava/sysdep/powerpc/locks.h.orig 2013-04-15 09:59:25.314991776 -0500
+++ libjava/sysdep/powerpc/locks.h 2013-04-15 10:04:24.744888106 -0500
@@ -25,7 +25,7 @@
obj_addr_t new_val)
{
return __atomic_compare_exchange_n (addr, &old, new_val, 0,
- __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
+ __ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE);
}
Ryan Arnold from IBM has a suspicion that it might be a problem in _Jv_MonitorEnter of libgcj. I've attached the _Jv_MonitorEnter section of the output of objdump -tdDsx /usr/lib/libgcj.so.13 from gcc-4.7.2 on Fedora 18 ppc to the bz as he wanted to compare that with the current one in gcc-4.8.0. Thanks & regards, Phil Created attachment 736352 [details]
_Jv_MonitorEnter disassembly of objdump libgcj of gcc-4.7.2 on ppc
At this point, this doesn't seem to be related to the compare_and_swap implementation since the problem persists even when the implementation is modified, and even when the locks.h implementation is entirely reverted to the gcc 4.7 version. I may have found a clue: Program received signal SIGSEGV, Segmentation fault. _Jv_Linker::ensure_method_table_complete (klass=klass@entry=0x60) at ../../../libjava/link.cc:1875 1875 if (klass->vtable != NULL) (gdb) bt #0 _Jv_Linker::ensure_method_table_complete (klass=klass@entry=0x60) at ../../../libjava/link.cc:1875 #1 0x0e282c58 in _Jv_Linker::wait_for_state (klass=0x60, klass@entry=0xf8a0ea8 <java::lang::ClassLoader::class$>, state=state@entry=9) at ../../../libjava/link.cc:2058 #2 0x0e2c2acc in java::lang::Class::initializeClass (this=0xf8a0ea8 <java::lang::ClassLoader::class$>) at ../../../libjava/java/lang/natClass.cc:728 #3 0x0e26e538 in _Jv_InitClass (klass=<optimized out>) at ../../../libjava/java/lang/Class.h:742 #4 _Jv_CreateJavaVM (vm_args=vm_args@entry=0x0) at ../../../libjava/prims.cc:1667 #5 0x0e26e5c4 in _Jv_RunMain (vm_args=vm_args@entry=0x0, klass=0x10020018 <gnu::classpath::tools::keytool::Main::class$>, name=name@entry=0x0, argc=10, argv=0xfffef6f4, is_jar=<optimized out>) at ../../../libjava/prims.cc:1720 #6 0x0e26e924 in _Jv_RunMain (klass=<optimized out>, name=name@entry=0x0, argc=<optimized out>, argv=<optimized out>, is_jar=is_jar@entry=false) at ../../../libjava/prims.cc:1815 #7 0x0e26e980 in JvRunMain (klass=<optimized out>, argc=<optimized out>, argv=<optimized out>) at ../../../libjava/prims.cc:1821 #8 0x0d1c17f4 in generic_start_main (main=0x100004c0 <main>, argc=10, ubp_av=0xfffef6f4, auxvec=0xfffef774, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>) at ../csu/libc-start.c:258 #9 0x0d1c1990 in __libc_start_main (argc=<optimized out>, ubp_av=<optimized out>, ubp_ev=<optimized out>, auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>, stack_on_entry=<optimized out>) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:91 #10 0x00000000 in ?? () Breakpoint 5, _Jv_Linker::wait_for_state (klass=0x60, klass@entry=0xf8a0ea8 <java::lang::ClassLoader::class$>, state=state@entry=9) at ../../../libjava/link.cc:2058 2058 ensure_method_table_complete (klass); klass: 0x60 (gdb) disass Dump of assembler code for function _Jv_Linker::wait_for_state(java::lang::Class*, int): 0x0e2829d0 <+0>: stwu r1,-48(r1) 0x0e2829d4 <+4>: mflr r0 0x0e2829d8 <+8>: bcl 20,4*cr7+so,0xe2829dc <_Jv_Linker::wait_for_state(java::lang::Class*, int)+12> 0x0e2829dc <+12>: stw r0,52(r1) 0x0e2829e0 <+16>: stw r30,40(r1) 0x0e2829e4 <+20>: mflr r30 0x0e2829e8 <+24>: stw r29,36(r1) 0x0e2829ec <+28>: stw r31,44(r1) 0x0e2829f0 <+32>: stw r26,24(r1) 0x0e2829f4 <+36>: stw r27,28(r1) 0x0e2829f8 <+40>: stw r28,32(r1) 0x0e2829fc <+44>: mr r31,r3 0x0e282a00 <+48>: mr r29,r4 0x0e282a04 <+52>: lbz r9,94(r3) 0x0e282a08 <+56>: addis r30,r30,333 0x0e282a0c <+60>: addi r30,r30,1620 0x0e282a10 <+64>: extsb r9,r9 0x0e282a14 <+68>: cmpw cr7,r9,r4 0x0e282a18 <+72>: blt cr7,0xe282a50 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+128> 0x0e282a1c <+76>: lwz r0,52(r1) 0x0e282a20 <+80>: lwz r26,24(r1) 0x0e282a24 <+84>: lwz r27,28(r1) 0x0e282a28 <+88>: lwz r28,32(r1) 0x0e282a2c <+92>: mtlr r0 0x0e282a30 <+96>: lwz r29,36(r1) 0x0e282a34 <+100>: lwz r30,40(r1) 0x0e282a38 <+104>: lwz r31,44(r1) 0x0e282a3c <+108>: addi r1,r1,48 0x0e282a40 <+112>: blr 0x0e282a44 <+116>: nop 0x0e282a48 <+120>: nop 0x0e282a4c <+124>: nop 0x0e282a50 <+128>: bl 0xe2cbe60 <java::lang::Thread::currentThread()> 0x0e282a54 <+132>: mr r28,r3 0x0e282a58 <+136>: mr r3,r31 0x0e282a5c <+140>: bl 0xe2c7170 <_Jv_MonitorEnter(jobject)> 0x0e282a60 <+144>: lbz r9,94(r31) 0x0e282a64 <+148>: extsb r9,r9 0x0e282a68 <+152>: cmpw cr7,r29,r9 0x0e282a6c <+156>: blt cr7,0xe282a90 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+192> 0x0e282a70 <+160>: lwz r9,96(r31) 0x0e282a74 <+164>: cmpwi cr7,r9,0 0x0e282a78 <+168>: beq cr7,0xe282a90 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+192> 0x0e282a7c <+172>: cmplw cr7,r28,r9 0x0e282a80 <+176>: beq cr7,0xe282a90 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+192> 0x0e282a84 <+180>: mr r3,r31 0x0e282a88 <+184>: bl 0xe2d8c20 <java.lang.Object.wait()void> 0x0e282a8c <+188>: b 0xe282a60 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+144> 0x0e282a90 <+192>: lwz r27,96(r31) 0x0e282a94 <+196>: stw r28,96(r31) 0x0e282a98 <+200>: mr r3,r31 0x0e282a9c <+204>: bl 0xee96ae0 <GC_base> 0x0e282aa0 <+208>: cmpwi cr7,r3,0 0x0e282aa4 <+212>: beq cr7,0xe282ac0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+240> 0x0e282aa8 <+216>: lwz r3,40(r31) 0x0e282aac <+220>: cmpwi cr7,r3,0 0x0e282ab0 <+224>: beq cr7,0xe282ac0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+240> 0x0e282ab4 <+228>: bl 0xee96ae0 <GC_base> 0x0e282ab8 <+232>: cmpwi cr7,r3,0 0x0e282abc <+236>: beq cr7,0xe282c84 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+692> 0x0e282ac0 <+240>: lbz r9,94(r31) 0x0e282ac4 <+244>: extsb r9,r9 0x0e282ac8 <+248>: cmpwi cr7,r9,6 0x0e282acc <+252>: beq cr7,0xe282bd0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+512> 0x0e282ad0 <+256>: cmpwi cr7,r9,1 0x0e282ad4 <+260>: beq cr7,0xe282bd0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+512> 0x0e282ad8 <+264>: cmpwi cr7,r29,2 0x0e282adc <+268>: ble cr7,0xe282b70 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+416> 0x0e282ae0 <+272>: lbz r9,94(r31) 0x0e282ae4 <+276>: extsb r9,r9 0x0e282ae8 <+280>: cmpwi cr7,r9,2 0x0e282aec <+284>: ble cr7,0xe282c00 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+560> 0x0e282af0 <+288>: cmpwi cr7,r29,4 0x0e282af4 <+292>: ble cr7,0xe282b70 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+416> 0x0e282af8 <+296>: lbz r9,94(r31) 0x0e282afc <+300>: extsb r9,r9 0x0e282b00 <+304>: cmpwi cr7,r9,4 0x0e282b04 <+308>: ble cr7,0xe282c50 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+640> 0x0e282b08 <+312>: cmpwi cr7,r29,6 0x0e282b0c <+316>: ble cr7,0xe282b70 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+416> 0x0e282b10 <+320>: lbz r9,94(r31) 0x0e282b14 <+324>: extsb r9,r9 0x0e282b18 <+328>: cmpwi cr7,r9,6 0x0e282b1c <+332>: ble cr7,0xe282c1c <_Jv_Linker::wait_for_state(java::lang::Class*, int)+588> 0x0e282b20 <+336>: cmpwi cr7,r29,8 0x0e282b24 <+340>: ble cr7,0xe282b70 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+416> 0x0e282b28 <+344>: lbz r9,94(r31) 0x0e282b2c <+348>: extsb r9,r9 0x0e282b30 <+352>: cmpwi cr7,r9,8 0x0e282b34 <+356>: bgt cr7,0xe282b70 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+416> 0x0e282b38 <+360>: lwz r9,-32600(r30) 0x0e282b3c <+364>: lbz r9,0(r9) 0x0e282b40 <+368>: cmpwi cr7,r9,0 0x0e282b44 <+372>: bne cr7,0xe282c78 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+680> 0x0e282b48 <+376>: mr r3,r31 0x0e282b4c <+380>: bl 0xe283950 <_Jv_Linker::ensure_class_linked(java::lang::Class*)> 0x0e282b50 <+384>: mr r3,r31 0x0e282b54 <+388>: bl 0xe282030 <_Jv_Linker::link_exception_table(java::lang::Class*)> 0x0e282b58 <+392>: mr r3,r31 0x0e282b5c <+396>: bl 0xe283c30 <_Jv_Linker::link_symbol_table(java::lang::Class*)> 0x0e282b60 <+400>: li r9,9 0x0e282b64 <+404>: stb r9,94(r31) 0x0e282b68 <+408>: mr r3,r31 0x0e282b6c <+412>: bl 0xe2c7ea0 <java::lang::Object::notifyAll()> 0x0e282b70 <+416>: stw r27,96(r31) 0x0e282b74 <+420>: lbz r9,94(r31) 0x0e282b78 <+424>: extsb r9,r9 0x0e282b7c <+428>: cmpwi cr7,r9,12 0x0e282b80 <+432>: beq cr7,0xe282cec <_Jv_Linker::wait_for_state(java::lang::Class*, int)+796> 0x0e282b84 <+436>: mr r3,r31 0x0e282b88 <+440>: bl 0xe2c74e0 <_Jv_MonitorExit(jobject)> 0x0e282b8c <+444>: lbz r9,94(r31) 0x0e282b90 <+448>: cmpwi cr7,r9,9 0x0e282b94 <+452>: bne cr7,0xe282a1c <_Jv_Linker::wait_for_state(java::lang::Class*, int)+76> 0x0e282b98 <+456>: cmpwi cr7,r29,8 0x0e282b9c <+460>: ble cr7,0xe282a1c <_Jv_Linker::wait_for_state(java::lang::Class*, int)+76> 0x0e282ba0 <+464>: lwz r9,-32596(r30) 0x0e282ba4 <+468>: lbz r9,0(r9) 0x0e282ba8 <+472>: cmpwi cr7,r9,0 0x0e282bac <+476>: beq cr7,0xe282a1c <_Jv_Linker::wait_for_state(java::lang::Class*, int)+76> 0x0e282bb0 <+480>: bl 0xe2cc7a0 <_Jv_GetCurrentJNIEnv()> 0x0e282bb4 <+484>: mr r4,r28 0x0e282bb8 <+488>: mr r6,r31 0x0e282bbc <+492>: mr r5,r3 0x0e282bc0 <+496>: li r3,56 0x0e282bc4 <+500>: crclr 4*cr1+eq 0x0e282bc8 <+504>: bl 0xe29da30 <_Jv_JVMTI_PostEvent(jvmtiEvent, java::lang::Thread*, ...)> 0x0e282bcc <+508>: b 0xe282a1c <_Jv_Linker::wait_for_state(java::lang::Class*, int)+76> 0x0e282bd0 <+512>: lhz r9,12(r31) 0x0e282bd4 <+516>: andi. r10,r9,4096 0x0e282bd8 <+520>: bne 0xe282ad8 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+264> 0x0e282bdc <+524>: lwz r9,-32592(r30) 0x0e282be0 <+528>: lbz r9,0(r9) 0x0e282be4 <+532>: cmpwi cr7,r9,0 0x0e282be8 <+536>: bne cr7,0xe282c6c <_Jv_Linker::wait_for_state(java::lang::Class*, int)+668> 0x0e282bec <+540>: lwz r9,-32604(r30) 0x0e282bf0 <+544>: lwz r10,0(r9) 0x0e282bf4 <+548>: addi r10,r10,1 0x0e282bf8 <+552>: stw r10,0(r9) 0x0e282bfc <+556>: b 0xe282ad8 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+264> 0x0e282c00 <+560>: mr r3,r31 0x0e282c04 <+564>: bl 0xe2846a0 <_Jv_Linker::ensure_supers_installed(java::lang::Class*)> 0x0e282c08 <+568>: li r9,3 0x0e282c0c <+572>: stb r9,94(r31) 0x0e282c10 <+576>: mr r3,r31 0x0e282c14 <+580>: bl 0xe2c7ea0 <java::lang::Object::notifyAll()> 0x0e282c18 <+584>: b 0xe282af0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+288> 0x0e282c1c <+588>: mr r3,r31 0x0e282c20 <+592>: bl 0xe284340 <_Jv_Linker::ensure_fields_laid_out(java::lang::Class*)> 0x0e282c24 <+596>: mr r3,r31 0x0e282c28 <+600>: bl 0xe282520 <_Jv_Linker::make_vtable(java::lang::Class*)> 0x0e282c2c <+604>: mr r3,r31 0x0e282c30 <+608>: bl 0xe282130 <_Jv_Linker::layout_interface_methods(java::lang::Class*)> 0x0e282c34 <+612>: mr r3,r31 0x0e282c38 <+616>: bl 0xe282f30 <_Jv_Linker::prepare_constant_time_tables(java::lang::Class*)> 0x0e282c3c <+620>: li r9,7 0x0e282c40 <+624>: stb r9,94(r31) 0x0e282c44 <+628>: mr r3,r31 0x0e282c48 <+632>: bl 0xe2c7ea0 <java::lang::Object::notifyAll()> 0x0e282c4c <+636>: b 0xe282b20 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+336> => 0x0e282c50 <+640>: mr r3,r31 0x0e282c54 <+644>: bl 0xe284930 <_Jv_Linker::ensure_method_table_complete(java::lang::Class*)> 0x0e282c58 <+648>: li r9,5 0x0e282c5c <+652>: stb r9,94(r31) 0x0e282c60 <+656>: mr r3,r31 0x0e282c64 <+660>: bl 0xe2c7ea0 <java::lang::Object::notifyAll()> 0x0e282c68 <+664>: b 0xe282b08 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+312> 0x0e282c6c <+668>: mr r3,r31 0x0e282c70 <+672>: bl 0xe282880 <_Jv_Linker::print_class_loaded(java::lang::Class*)> 0x0e282c74 <+676>: b 0xe282bec <_Jv_Linker::wait_for_state(java::lang::Class*, int)+540> 0x0e282c78 <+680>: mr r3,r31 0x0e282c7c <+684>: bl 0xe282690 <_Jv_Linker::verify_class(java::lang::Class*)> 0x0e282c80 <+688>: b 0xe282b48 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+376> 0x0e282c84 <+692>: lhz r9,48(r31) 0x0e282c88 <+696>: extsh. r26,r9 0x0e282c8c <+700>: beq 0xe282ac0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+240> 0x0e282c90 <+704>: rlwinm r26,r26,4,0,27 0x0e282c94 <+708>: mr r3,r26 0x0e282c98 <+712>: bl 0xe2d6980 <_Jv_AllocRawObj(int)> 0x0e282c9c <+716>: lwz r4,40(r31) 0x0e282ca0 <+720>: mr r5,r26 0x0e282ca4 <+724>: bl 0xee9f680 <00008000.got2.plt_pic32.memcpy@@GLIBC_2.0+384> 0x0e282ca8 <+728>: stw r3,40(r31) 0x0e282cac <+732>: b 0xe282ac0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+240> 0x0e282cb0 <+736>: cmpwi cr7,r4,1 0x0e282cb4 <+740>: bne cr7,0xe282cd8 <_Jv_Linker::wait_for_state(java::lang::Class*, int)+776> 0x0e282cb8 <+744>: lwz r29,-4(r3) 0x0e282cbc <+748>: stw r27,96(r31) 0x0e282cc0 <+752>: li r9,12 0x0e282cc4 <+756>: stb r9,94(r31) 0x0e282cc8 <+760>: mr r3,r31 0x0e282ccc <+764>: bl 0xe2c7ea0 <java::lang::Object::notifyAll()> 0x0e282cd0 <+768>: mr r3,r29 0x0e282cd4 <+772>: bl 0xe27e690 <_Jv_Throw(jthrowable)> 0x0e282cd8 <+776>: mr r29,r3 0x0e282cdc <+780>: mr r3,r31 0x0e282ce0 <+784>: bl 0xe2c74e0 <_Jv_MonitorExit(jobject)> 0x0e282ce4 <+788>: mr r3,r29 0x0e282ce8 <+792>: bl 0xeea0fd0 <00008000.got2.plt_pic32._Unwind_Resume@@GCC_3.0+3760> 0x0e282cec <+796>: lwz r3,-32720(r30) 0x0e282cf0 <+800>: bl 0xe26c610 <_Jv_AllocObject(jclass)> 0x0e282cf4 <+804>: mr r29,r3 0x0e282cf8 <+808>: bl 0xe70e410 <java.lang.LinkageError.LinkageError()> 0x0e282cfc <+812>: mr r3,r29 0x0e282d00 <+816>: bl 0xe27e690 <_Jv_Throw(jthrowable)> End of assembler dump. (gdb) si 0x0e282c54 2058 ensure_method_table_complete (klass); (gdb) info reg r3 r3 0x60 96 Sure enough, ensure_method_table_complete() is called with the 'this' pointer value for the static function _Jv_Linker::wait_for_state() is passed in klass=0x60, instead of the value of klass@entry=0xf8a0ea8. In fact, there is no three parameter version of wait_for_state. Since _Jv_Linker::wait_for_state is a static function shouldn't this be? _Jv_Linker::wait_for_state (klass=klass@entry=0xf8a0ea8 <java::lang::ClassLoader::class$>, state=state@entry=9) I suspect, otherwise, the static function _Jv_Linker::wait_for_state will return a bogus this pointer (as we're seeing).. and this is being passed to _Jv_Linker::ensure_method_table_complete (klass=klass@entry=0x60) Further analysis. Looking at wait_for_state right on entry:
Breakpoint 5, _Jv_Linker::wait_for_state (klass=0x60, klass@entry=0xf8a0ea8 <java::lang::ClassLoader::class$>, state=state@entry=9) at ../../../libjava/link.cc:2002
2002 {
klass: 0x60
(gdb) disass
Dump of assembler code for function _Jv_Linker::wait_for_state(java::lang::Class*, int):
=> 0x0e2829d0 <+0>: stwu r1,-48(r1)
0x0e2829d4 <+4>: mflr r0
0x0e2829d8 <+8>: bcl 20,4*cr7+so,0xe2829dc <_Jv_Linker::wait_for_state(java::lang::Class*, int)+12>
0x0e2829dc <+12>: stw r0,52(r1)
0x0e2829e0 <+16>: stw r30,40(r1)
0x0e2829e4 <+20>: mflr r30
0x0e2829e8 <+24>: stw r29,36(r1)
(gdb) info reg r3
r3 0x60 96
It's obvious that r3 is passed in a bogus value. It should be a valid object address from InitializeClass 'this':
java::lang::Class::initializeClass (void)
{
// Short-circuit to avoid needless locking (expression includes
// JV_STATE_PHANTOM and JV_STATE_DONE).
if (state >= JV_STATE_PHANTOM)
return;
// Step 1. We introduce a new scope so we can synchronize more
// easily.
{
JvSynchronize sync (this);
if (state < JV_STATE_LINKED)
{
try
{
_Jv_Linker::wait_for_state(this, JV_STATE_LINKED);
Here's the LR to InitializeClass:
0x0e2c2acc
And the surrounding asm:
0x0e2c29a0 <+112>: bl 0xe2c7170 <_Jv_MonitorEnter(jobject)>
0x0e2c29a4 <+116>: lbz r9,94(r31)
0x0e2c29a8 <+120>: extsb r9,r9
0x0e2c29ac <+124>: cmpwi cr7,r9,8
0x0e2c29b0 <+128>: ble cr7,0xe2c2ac0 <java::lang::Class::initializeClass()+400>
.....
0x0e2c2ab8 <+392>: nop
0x0e2c2abc <+396>: nop
0x0e2c2ac0 <+400>: mr r3,r31
0x0e2c2ac4 <+404>: li r4,9
0x0e2c2ac8 <+408>: bl 0xe2829d0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)>
0x0e2c2acc <+412>: b 0xe2c29b4 <java::lang::Class::initializeClass()+132>
So it looks like r3 is being restored from r31, which is a non-volatile. So I suspect that _Jv_MonitorEnter is either clobbering r31, or it's clobbering the stack where r31 is saved.
Looking at the _Jv_MonitorEnter() asm prologue:
(gdb) disass _Jv_MonitorEnter
Dump of assembler code for function _Jv_MonitorEnter(jobject):
0x0e2c7170 <+0>: stwu r1,-64(r1)
0x0e2c7174 <+4>: mflr r0
0x0e2c7178 <+8>: bcl 20,4*cr7+so,0xe2c717c <_Jv_MonitorEnter(jobject)+12>
0x0e2c717c <+12>: stw r30,56(r1)
0x0e2c7180 <+16>: stw r29,52(r1)
0x0e2c7184 <+20>: mflr r30
0x0e2c7188 <+24>: srawi r29,r3,10
0x0e2c718c <+28>: xor r29,r29,r3
0x0e2c7190 <+32>: stw r31,60(r1)
It _is_ saving r31 to the stack. I'll need to look at _Jv_MonitorEnter in depth.
Tracing into _Jv_MonitorEnter in this erroneous/error path:
(gdb) break *0x0e2c7234
Breakpoint 9 at 0xe2c7234: file ../../../libjava/java/lang/natObject.cc, line 1016.
(gdb) c
Continuing.
Breakpoint 9, 0x0e2c7234 in _Jv_MonitorEnter (obj=<optimized out>) at ../../../libjava/java/lang/natObject.cc:1016
1016 }
(gdb) disass
(gdb) disass
Dump of assembler code for function _Jv_MonitorEnter(jobject):
0x0e2c7170 <+0>: stwu r1,-64(r1)
0x0e2c7174 <+4>: mflr r0
0x0e2c7178 <+8>: bcl 20,4*cr7+so,0xe2c717c <_Jv_MonitorEnter(jobject)+12>
0x0e2c717c <+12>: stw r30,56(r1)
0x0e2c7180 <+16>: stw r29,52(r1)
0x0e2c7184 <+20>: mflr r30
0x0e2c7188 <+24>: srawi r29,r3,10
0x0e2c718c <+28>: xor r29,r29,r3
0x0e2c7190 <+32>: stw r31,60(r1)
0x0e2c7194 <+36>: rlwinm r29,r29,4,17,27
0x0e2c7198 <+40>: mr r31,r3
0x0e2c719c <+44>: stw r0,68(r1)
0x0e2c71a0 <+48>: stw r24,32(r1)
0x0e2c71a4 <+52>: stw r25,36(r1)
0x0e2c71a8 <+56>: stw r26,40(r1)
0x0e2c71ac <+60>: addis r30,r30,329
0x0e2c71b0 <+64>: stw r27,44(r1)
0x0e2c71b4 <+68>: addi r30,r30,-13028
0x0e2c71b8 <+72>: stw r28,48(r1)
0x0e2c71bc <+76>: lwz r9,-32756(r30)
0x0e2c71c0 <+80>: add r29,r29,r9
0x0e2c71c4 <+84>: bl 0xeea19b0 <00008000.got2.plt_pic32.pthread_self@@GLIBC_2.0+96>
0x0e2c71c8 <+88>: cmpwi cr7,r31,0
0x0e2c71cc <+92>: beq cr7,0xe2c7238 <_Jv_MonitorEnter(jobject)+200>
0x0e2c71d0 <+96>: mr r28,r3
0x0e2c71d4 <+100>: addi r26,r1,20
0x0e2c71d8 <+104>: li r27,0
0x0e2c71dc <+108>: stw r27,20(r1)
0x0e2c71e0 <+112>: li r10,0
0x0e2c71e4 <+116>: lwarx r9,0,r29
0x0e2c71e8 <+120>: cmpw r9,r10
0x0e2c71ec <+124>: bne 0xe2c71f8 <_Jv_MonitorEnter(jobject)+136>
0x0e2c71f0 <+128>: stwcx. r31,0,r29
0x0e2c71f4 <+132>: bne 0xe2c71e4 <_Jv_MonitorEnter(jobject)+116>
0x0e2c71f8 <+136>: isync
0x0e2c71fc <+140>: stw r9,0(r26)
0x0e2c7200 <+144>: bne 0xe2c7250 <_Jv_MonitorEnter(jobject)+224>
0x0e2c7204 <+148>: stw r28,4(r29)
0x0e2c7208 <+152>: lwz r0,68(r1)
0x0e2c720c <+156>: lwz r24,32(r1)
0x0e2c7210 <+160>: lwz r25,36(r1)
0x0e2c7214 <+164>: lwz r26,40(r1)
0x0e2c7218 <+168>: mtlr r0
0x0e2c721c <+172>: lwz r27,44(r1)
0x0e2c7220 <+176>: lwz r28,48(r1)
0x0e2c7224 <+180>: lwz r29,52(r1)
0x0e2c7228 <+184>: lwz r30,56(r1)
0x0e2c722c <+188>: lwz r31,60(r1)
0x0e2c7230 <+192>: addi r1,r1,64
=> 0x0e2c7234 <+196>: blr
(gdb) info reg r31
r31 0xf8a0ea8 260705960
(gdb) si
java::lang::Class::initializeClass (this=0xf8a0ea8 <java::lang::ClassLoader::class$>) at ../../../libjava/java/lang/natClass.cc:724
724 if (state < JV_STATE_LINKED)
(gdb) disass
Dump of assembler code for function java::lang::Class::initializeClass():
0x0e2c2930 <+0>: stwu r1,-48(r1)
0x0e2c2934 <+4>: mflr r0
0x0e2c2938 <+8>: bcl 20,4*cr7+so,0xe2c293c <java::lang::Class::initializeClass()+12>
0x0e2c293c <+12>: stw r0,52(r1)
0x0e2c2940 <+16>: stw r30,40(r1)
0x0e2c2944 <+20>: mflr r30
0x0e2c2948 <+24>: stw r31,44(r1)
0x0e2c294c <+28>: stw r27,28(r1)
0x0e2c2950 <+32>: stw r28,32(r1)
0x0e2c2954 <+36>: stw r29,36(r1)
0x0e2c2958 <+40>: mr r31,r3
0x0e2c295c <+44>: lbz r9,94(r3)
0x0e2c2960 <+48>: addis r30,r30,329
0x0e2c2964 <+52>: addi r30,r30,5128
0x0e2c2968 <+56>: extsb r9,r9
0x0e2c296c <+60>: cmpwi cr7,r9,12
0x0e2c2970 <+64>: ble cr7,0xe2c29a0 <java::lang::Class::initializeClass()+112>
0x0e2c2974 <+68>: lwz r0,52(r1)
0x0e2c2978 <+72>: lwz r27,28(r1)
0x0e2c297c <+76>: lwz r28,32(r1)
0x0e2c2980 <+80>: lwz r29,36(r1)
0x0e2c2984 <+84>: mtlr r0
0x0e2c2988 <+88>: lwz r30,40(r1)
0x0e2c298c <+92>: lwz r31,44(r1)
0x0e2c2990 <+96>: addi r1,r1,48
0x0e2c2994 <+100>: blr
0x0e2c2998 <+104>: nop
0x0e2c299c <+108>: nop
0x0e2c29a0 <+112>: bl 0xe2c7170 <_Jv_MonitorEnter(jobject)>
=> 0x0e2c29a4 <+116>: lbz r9,94(r31)
0x0e2c29a8 <+120>: extsb r9,r9
0x0e2c29ac <+124>: cmpwi cr7,r9,8
0x0e2c29b0 <+128>: ble cr7,0xe2c2ac0 <java::lang::Class::initializeClass()+400>
0x0e2c29b4 <+132>: bl 0xe2cbe60 <java::lang::Thread::currentThread()>
0x0e2c29b8 <+136>: ori r29,r3,1
0x0e2c29bc <+140>: nop
0x0e2c29c0 <+144>: lbz r9,94(r31)
0x0e2c29c4 <+148>: extsb r9,r9
0x0e2c29c8 <+152>: cmpwi cr7,r9,10
0x0e2c29cc <+156>: bne cr7,0xe2c29f0 <java::lang::Class::initializeClass()+192>
0x0e2c29d0 <+160>: lwz r9,96(r31)
0x0e2c29d4 <+164>: cmpwi cr7,r9,0
0x0e2c29d8 <+168>: beq cr7,0xe2c2a8c <java::lang::Class::initializeClass()+348>
0x0e2c29dc <+172>: cmplw cr7,r29,r9
0x0e2c29e0 <+176>: beq cr7,0xe2c2a8c <java::lang::Class::initializeClass()+348>
0x0e2c29e4 <+180>: mr r3,r31
0x0e2c29e8 <+184>: bl 0xe2d8c20 <java.lang.Object.wait()void>
0x0e2c29ec <+188>: b 0xe2c29c0 <java::lang::Class::initializeClass()+144>
0x0e2c29f0 <+192>: cmpwi cr7,r9,14
0x0e2c29f4 <+196>: beq cr7,0xe2c2a8c <java::lang::Class::initializeClass()+348>
0x0e2c29f8 <+200>: cmpwi cr7,r9,12
0x0e2c29fc <+204>: beq cr7,0xe2c2c0c <java::lang::Class::initializeClass()+732>
0x0e2c2a00 <+208>: stw r29,96(r31)
0x0e2c2a04 <+212>: mr r3,r31
0x0e2c2a08 <+216>: li r4,9
0x0e2c2a0c <+220>: bl 0xe2829d0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)>
0x0e2c2a10 <+224>: li r9,10
So it looks like _Jv_MonitorEnter didn't clobber r31.
It executes the following four instructions:
0x0e2c29a0 <+112>: bl 0xe2c7170 <_Jv_MonitorEnter(jobject)>
=> 0x0e2c29a4 <+116>: lbz r9,94(r31)
0x0e2c29a8 <+120>: extsb r9,r9
0x0e2c29ac <+124>: cmpwi cr7,r9,8
0x0e2c29b0 <+128>: ble cr7,0xe2c2ac0 <java::lang::Class::initializeClass()+400>
and jumps to:
=> 0x0e2c2ac0 <+400>: mr r3,r31
0x0e2c2ac4 <+404>: li r4,9
0x0e2c2ac8 <+408>: bl 0xe2829d0 <_Jv_Linker::wait_for_state(java::lang::Class*, int)>
And then:
(gdb) info reg r31
r31 0xf8a0ea8 260705960
(gdb) info reg r3
r3 0xf7fe3c60 4160633952
(gdb) si
0x0e2c2ac4 728 _Jv_Linker::wait_for_state(this, JV_STATE_LINKED);
(gdb) si
0x0e2c2ac8 728 _Jv_Linker::wait_for_state(this, JV_STATE_LINKED);
(gdb) info reg r3
r3 0xf8a0ea8 260705960
(gdb) si
Breakpoint 5, _Jv_Linker::wait_for_state (klass=0x60, klass@entry=0xf8a0ea8 <java::lang::ClassLoader::class$>, state=state@entry=9) at ../../../libjava/link.cc:2002
2002 {
$2 = "ZINGGGG"
klass: 0x60
(gdb) info reg r3
r3 0x60 96
(gdb)
uhmmmmm.... how did r3 just change across a single step?
So I was 'breaking' conditionally in gdb and the failure path was a different thread.
Alright, news from my side: the git bisect run has finished with a single commit as a result: ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit commit ff2a5adaa72fef87cac689a40c23258a30b304c8 Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Sun Apr 22 21:28:07 2012 +0000 I've attached the git diff 62c34bfbaa44da92a4c3cb45314370d19b0d324c..ff2a5adaa72fef87cac689a40c23258a30b304c8 output as attachment. The patch is rather big but from a first glance it doesn't touch any java or power specific stuff. If anyone with a bit more insight into that part of gcc could take a peek at it and figure how it is related to the error we're seeing that would be great! Thanks & regards, Phil Created attachment 737191 [details]
git diff between last good and first bad state of the git bisect run
Steps i did:
git clone git://gcc.gnu.org/git/gcc.git
git bisect start HEAD 37ef1b77a236a9e8776a9d81416adfc22fde0be8 --
git bisect run sh -c "cd /root/objdir/ && rm -rf * && ../gcc/configure --build=ppc-redhat-linux --target=ppc-redhat-linux --enable-languages=c,c++,java --disable-multilib --disable-mudflap --disable-libstdcxx-pch && make -j 8 || exit 125; echo '' | ../objdir/ppc-redhat-linux/libjava/gkeytool -list"
Thanks & regards, Phil
Hm, seems i marked the patch as private for some odd reason. Fixed. Though as written in comment #7 you can recreate the patch with the above mentioned git command easily. Thanks to Florian Weimer he inspected the patch and only found one reference to java. He then went ahead and created a patch similar to other frontends, but unfortunately this didn't fix the issue. His guess now is that this might be a side effect of a bug in the ppc 32bit gcc backend or a libgcj issue that only gets triggered on ppc 32bit. His suggestion would be to compile libgcj with and without the patch and look where differences are, maybe that would give a hint as to why and where this gets triggered. Thanks & regards, Phil This bug is blocking kernel updates on f19 for ppc64. Newer kernels (> rc7) were built on primary with java-1.5.0-gcj-1.5.0.0-42.fc19 in the buildroot. Secondary arches have to have the same (or newer) NVRs in the buildroot as primary. Upstream bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Recreated upstream with GCC 4.8 so I created the following GCC bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Sorry that i'm posting my result here, but unfortunately i don't have a gnu.org account. Peter Bergner notified my about Jakub's latest patch from here: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00178.html So i checked out the gcc-4_8-branch, applied Jakubs patch and did "my" bootstrap on ppc 32bit it via: cd /root/objdir/ && rm -rf * && ../gcc/configure --build=ppc-redhat-linux --target=ppc-redhat-linux --enable-languages=c,c++,java --disable-multilib --disable-mudflap --disable-libstdcxx-pch && make -j 8 The test i ran that always failed was: ../objdir/ppc-redhat-linux/libjava/gkeytool --list and with the patch it now runs successful! Summary: Jakub's latest patch fixes the problem on ppc 32bit as well. Thanks! Regards, Phil PS: It would be great if we could get a gcc build with that fix for Fedora 19 as we're accumulating quite a few chain failed builds due to that. Created attachment 744284 [details] java-1.5.0-gcj build log I applied Jakub's latest patch on top of gcc-4.8.0-1.fc19. http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00178.html gcc built fine and it makes gkeytool work. However, java-1.5.0-gcj still fails to build. Attached the build log. java-1.5.0-gcj is the one that is currently blocking a lot of packages on ppc. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. ------- Comment From ryanarn.com 2013-04-17 21:05 EDT------- ------- Comment From ryanarn.com 2013-04-17 21:30 EDT------- ------- Comment From ryanarn.com 2013-04-17 22:00 EDT------- ------- Comment From ryanarn.com 2013-04-17 22:06 EDT------- ------- Comment From ryanarn.com 2013-04-25 19:53 EDT------- Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. ------- Comment From azanella.com 2015-03-09 14:00 EDT------- Closing this bug due comment #19. If this still fails for Fedora 20+, please a open a new one. |