This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 147968 - AbstractMethodError exception
AbstractMethodError exception
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc4 (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-14 04:31 EST by Caolan McNamara
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 4.0.0-0.28
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-23 20:11:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
testcase (431.52 KB, application/x-gzip)
2005-02-14 06:59 EST, Caolan McNamara
no flags Details

  None (edit)
Description Caolan McNamara 2005-02-14 04:31:56 EST
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 04:49:11 EST
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 06:59:28 EST
Created attachment 111048 [details]
testcase

This seems to reproduce it.
Comment 3 Caolan McNamara 2005-02-14 07:06:26 EST
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 07:50:30 EST
That seems to be the problem alright.
Comment 5 Jakub Jelinek 2005-02-14 09:42:34 EST
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 11:11:49 EST
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 17:02:18 EST
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 13:08:52 EST
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 14:34:16 EST
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 00:20:01 EST
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-23 20:11:07 EST
Should be fixed in gcc4-4.0.0-0.28.

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