Bug 147968
Summary: | AbstractMethodError exception | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Caolan McNamara <caolanm> | ||||
Component: | gcc4 | Assignee: | Jakub Jelinek <jakub> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | 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
Caolan McNamara
2005-02-14 09:31:56 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. Created attachment 111048 [details]
testcase
This seems to reproduce it.
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. That seems to be the problem alright. 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. 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. 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. 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 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. 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. Should be fixed in gcc4-4.0.0-0.28. |