Bug 147968

Summary: AbstractMethodError exception
Product: [Fedora] Fedora Reporter: Caolan McNamara <caolanm>
Component: gcc4Assignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: aph, dwmw2, tromey
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 4.0.0-0.28 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-24 01:11:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
testcase none

Description Caolan McNamara 2005-02-14 09:31:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220

Description of problem:
OpenOffice.org2's build time java stuff works fine with gcj, until friday feb 11th that is. Spec and source for OOo2 remained unchanged while this error has materialized

Exception in thread "main" java.lang.AbstractMethodError: normalize ()V    at _Jv_Linker.make_vtable(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0)
   at _Jv_Linker.wait_for_state(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0)
   at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj_fc4.so.6.0.0)
   at _Jv_Linker.resolve_pool_entry(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0)
   at com.sun.star.help.HelpCompiler.compile() (Unknown Source)


Version-Release number of selected component (if applicable):
libgcj-3.4.3-19

How reproducible:
Always

Steps to Reproduce:
1. If it's not already a known problem I can try and isolate a smaller test case.

Additional info:

Comment 1 Jakub Jelinek 2005-02-14 09:49:11 UTC
Can you get exact package versions where it worked and where it doesn't?
If you are using glibc-2.3.4-{7,8,9}, don't.
Between libgcj-3.4.3-18 and -19 there were certainly no changes that would matter
for this.

Comment 2 Caolan McNamara 2005-02-14 11:59:28 UTC
Created attachment 111048 [details]
testcase

This seems to reproduce it.

Comment 3 Caolan McNamara 2005-02-14 12:06:26 UTC
OOo2 has to use libgcj4, so perhaps my problem arises out of a libgcj issue
between gcc4-4.0.0-0.22 -> gcc4-4.0.0-0.23, I'll downgrade my own version and
give that theory a test.

Comment 4 Caolan McNamara 2005-02-14 12:50:30 UTC
That seems to be the problem alright.

Comment 5 Jakub Jelinek 2005-02-14 14:42:34 UTC
Doesn't seem to be gcc4 nor -0.22 -> 0.23 specific:

$ mkdir -p /tmp/gcj4xx
$ cd /tmp/gcj44xx; rpm2cpio
/mnt/redhat/beehive/comps/dist/fc4/gcc4/4.0.0-0.22/i386/libgcj4-4.0.0-0.22.i386.rpm; cd -
$ CLASSPATH=jaxp.jar:parser.jar:xt.jar:. gij whyme
Exception in thread "main" java.lang.AbstractMethodError
   at _Jv_MakeVTable(java.lang.Class) (/usr/lib/libgcj.so.5.0.0)
   at _Jv_PrepareClass(java.lang.Class) (/usr/lib/libgcj.so.5.0.0)
   at _Jv_WaitForState(java.lang.Class, int) (/usr/lib/libgcj.so.5.0.0)
   at java.lang.VMClassLoader.linkClass0(java.lang.Class)
(/usr/lib/libgcj.so.5.0.0)
   at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/usr/lib/libgcj.so.5.0.0)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.5.0.0)
   at _Jv_ResolvePoolEntry(java.lang.Class, int) (/usr/lib/libgcj.so.5.0.0)
   at whyme.main(java.lang.String[]) (Unknown Source)
$ CLASSPATH=jaxp.jar:parser.jar:xt.jar:. gij4 whyme
Exception in thread "main" java.lang.AbstractMethodError: normalize ()V
   at _Jv_Linker.make_vtable(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0)
   at _Jv_Linker.wait_for_state(java.lang.Class, int)
(/usr/lib/libgcj_fc4.so.6.0.0)
   at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/usr/lib/libgcj_fc4.so.6.0.0)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj_fc4.so.6.0.0)
   at _Jv_Linker.resolve_pool_entry(java.lang.Class, int)
(/usr/lib/libgcj_fc4.so.6.0.0)
   at whyme.main(java.lang.String[]) (Unknown Source)
$ LD_PRELOAD=/tmp/gcj4xx/usr/lib/libgij_fc4.so.6:/usr/lib/libgcj_fc4.so.6
LD_LIBRARY_PATH=/tmp/gcj4xx/usr/lib CLASSPATH=jaxp.ja
Exception in thread "main" java.lang.AbstractMethodError: normalize ()V
   at _Jv_Linker.make_vtable(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0)
   at _Jv_Linker.wait_for_state(java.lang.Class, int)
(/usr/lib/libgcj_fc4.so.6.0.0)
   at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/usr/lib/libgcj_fc4.so.6.0.0)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj_fc4.so.6.0.0)
   at _Jv_Linker.resolve_pool_entry(java.lang.Class, int)
(/usr/lib/libgcj_fc4.so.6.0.0)
   at whyme.main(java.lang.String[]) (Unknown Source)
$ rpm -q libgcj libgcj4
libgcj-3.4.3-19
libgcj4-4.0.0-0.23

Which means it fails with all 3 versions.

Comment 6 Jakub Jelinek 2005-02-14 16:11:49 UTC
FYI, this is _Jv_Linker::make_vtable called on com.sun.xml.tree.XmlDocument
class.
gdb doesn't work on gij, but it seems last klass in make_vtable loop to
find the normalize ()V abstract class was com.sun.xml.tree.NodeBase.

Comment 7 Tom Tromey 2005-02-16 22:02:18 UTC
I don't see this problem with cvs head, but that is simply
because we've merged in GNU JAXP, so all the core xml-related
parser classes are now built in to libgcj.

So, this is may be just hiding the real bug.
On the other hand, linking com.sun.xml.tree.XmlDocument
definitely is working here; another explanation could be
that we've updated org.xml.sax.



Comment 8 Tom Tromey 2005-02-17 18:08:52 UTC
Ignore comment #7.  I had a patch in my tree that disabled
a check in this area, and I forgot that.  When I back this
out I can reproduce this bug.  I'm looking into this


Comment 9 Tom Tromey 2005-02-17 19:34:16 UTC
Ok, the bug here starts with the fact that the w3c, unfortunately,
violated java binary compatibility rules and added a method to an
interface.

Right now libgcj includes a newer version of org.w3c.dom.
Because it is directly in the library, this means that
the version of Node in the library is picked up in preference
to the one in parser.jar.

com.sun.xml.tree.NodeBase implements Node, but does not override
the new normalize() method.  This is "ok" since this class is
abstract, as is com.sun.xml.tree.ParentNode.  However,
com.sun.xml.tree.XmlDocument is not, and it inherits the
abstract method, leading to a runtime link error.

First, how does this work on proprietary JVMs?  My understanding
is that the only way to override org.w3c.dom is to find it via
the "java.endorsed.dirs" feature... is this what OOo does?

Fixing this in libgcj is kind of tricky.  It involves splitting
up the library into some components.  It is possible, we've talked
about it already a couple of times...

Another approach would be to change this code in OOo so that it
uses the current version of org.w3c.dom and friends.


Comment 10 Tom Tromey 2005-02-19 05:20:01 UTC
Today I happened to run across a clarification to the JVMS
that, inexplicably, I hadn't seen before.

It seems we do not need to throw an AbstractMethodError
during linking; instead, the error can be caught when the
method is actually called.

I checked in a patch to change this.
With this patch the test case works for me.




Comment 11 Jakub Jelinek 2005-02-24 01:11:07 UTC
Should be fixed in gcc4-4.0.0-0.28.