Bug 952673 - gcc-4.8.0 libgcj regression on 32bit Power architecture
gcc-4.8.0 libgcj regression on 32bit Power architecture
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
19
ppc Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F19PPCBeta/F19PPCBetaBlocker/PPCBetaBlocker
  Show dependency treegraph
 
Reported: 2013-04-16 08:17 EDT by Phil Knirsch
Modified: 2015-03-09 10:10 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 09:59:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
_Jv_MonitorEnter disassembly of objdump libgcj of gcc-4.7.2 on ppc (10.40 KB, text/plain)
2013-04-16 10:53 EDT, Phil Knirsch
no flags Details
git diff between last good and first bad state of the git bisect run (64.82 KB, patch)
2013-04-18 03:40 EDT, Phil Knirsch
no flags Details | Diff
java-1.5.0-gcj build log (632.07 KB, text/plain)
2013-05-06 14:09 EDT, Gustavo Luiz Duarte
no flags Details

  None (edit)
Description Phil Knirsch 2013-04-16 08:17:59 EDT
When trying to rebuild java-1.5.0-gcj on Fedora 19 ppc it failed very early while tyring to generate the cacert file using the gkeytool with the following error:

bash-4.2# gkeytool
Exception in thread "main" java.lang.NoClassDefFoundError: gnu.classpath.tools.keytool.Main
   at java.lang.Class.initializeClass(libgcj.so.14)
Caused by: java.lang.IllegalMonitorStateException: current thread not owner
   at java.lang.Object.notifyAll(libgcj.so.14)
   at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.14)
   at java.lang.ClassLoader.loadClass(libgcj.so.14)
   at java.lang.ClassLoader.loadClass(libgcj.so.14)
   at java.lang.Class.initializeClass(libgcj.so.14)

The same works fine on ppc64 and also on Fedora 18 for both ppc and ppc64 for gcc-4.7.

Just rebuilding gcc-4.8.0 on Fedora 18 ppc also shows the same error.

One of the changes between gcc-4.7 and gcc-4.8 we though might trigger it was this:

http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/sysdep/powerpc/locks.h?view=log
http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/sysdep/powerpc/locks.h?r1=184997&r2=188833&view=patch

But it turned out that this wasn't the culprit, the error still occurs even after a patch -r and a rebuild.

I've currently set up a git bisect run from gcc git upstream to see if i can locate the patch that causes this regression between gcc-4.7 and gcc-4.8, but i expect this to take a few days.

If you need any further info or access to a machine where this problem happens please let me know and i'll be happy to provide assistance.

Thanks & regards, Phil
Comment 1 Brent Baude 2013-04-16 08:30:08 EDT
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);
 }
Comment 2 Phil Knirsch 2013-04-16 10:52:32 EDT
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
Comment 3 Phil Knirsch 2013-04-16 10:53:38 EDT
Created attachment 736352 [details]
_Jv_MonitorEnter disassembly of objdump libgcj of gcc-4.7.2 on ppc
Comment 4 IBM Bug Proxy 2013-04-17 17:10:35 EDT
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)
Comment 5 IBM Bug Proxy 2013-04-17 17:41:20 EDT
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.
Comment 6 IBM Bug Proxy 2013-04-17 18:10:35 EDT
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.
Comment 7 Phil Knirsch 2013-04-18 03:38:23 EDT
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
Comment 8 Phil Knirsch 2013-04-18 03:40:32 EDT
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
Comment 9 Phil Knirsch 2013-04-24 08:28:25 EDT
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
Comment 10 Gustavo Luiz Duarte 2013-04-25 15:59:23 EDT
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.
Comment 11 Gustavo Luiz Duarte 2013-04-25 16:01:35 EDT
Upstream bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
Comment 12 IBM Bug Proxy 2013-04-25 16:02:26 EDT
Recreated upstream with GCC 4.8 so I created the following GCC bug.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
Comment 13 Phil Knirsch 2013-05-06 12:03:58 EDT
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.
Comment 14 Gustavo Luiz Duarte 2013-05-06 14:09:00 EDT
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.
Comment 15 Fedora End Of Life 2015-01-09 12:53:58 EST
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 16 IBM Bug Proxy 2015-01-09 13:03:40 EST
------- Comment From ryanarn@us.ibm.com 2013-04-17 21:05 EDT-------

------- Comment From ryanarn@us.ibm.com 2013-04-17 21:30 EDT-------




------- Comment From ryanarn@us.ibm.com 2013-04-17 22:00 EDT-------

------- Comment From ryanarn@us.ibm.com 2013-04-17 22:06 EDT-------

------- Comment From ryanarn@us.ibm.com 2013-04-25 19:53 EDT-------
Comment 17 Fedora End Of Life 2015-02-17 09:59:39 EST
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 18 IBM Bug Proxy 2015-03-09 10:10:29 EDT
------- Comment From azanella@br.ibm.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.

Note You need to log in before you can comment on or make changes to this bug.