Red Hat Bugzilla – Bug 154634
[gcj]Saving as docbook xml fails with java.lang.IllegalAccessError: XSLTransformer$1
Last modified: 2007-11-30 17:11:03 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Galeon/1.3.20 (Debian package 1.3.20-1) Description of problem: Trying to save an text document as Docbook XML fails and gives the following output on the console: Exception in thread "Thread-66" Reaped unknown child pid = 17562 Reaped unknown child pid = 17564 Reaped unknown child pid = 17566 Reaped unknown child pid = 17568 java.lang.IllegalAccessError: XSLTransformer$1: XSLTransformer.statsp at XSLTransformer$1.run() (Unknown Source) at .GC_start_routine (/usr/lib/libgcj.so.6.0.0) at .__clone (/lib/libc-2.3.4.so) Version-Release number of selected component (if applicable): 1.9.92-1 How reproducible: Always Steps to Reproduce: 1. File -> New -> Text Document 2. Type some text 3. File -> Save 4. Browse for other folders 5. Select Docbook (.xml) 6. Save (Click yes on formatting dialog) Actual Results: Error dialog: Error while saving document Untitled1: Write error. File could not be written. And the output in the console described above: Exception in thread "Thread-16" java.lang.IllegalAccessError: XSLTransformer$1: XSLTransformer.statsp at XSLTransformer$1.run() (Unknown Source) at .GC_start_routine (/usr/lib/libgcj.so.6.0.0) at .__clone (/lib/libc-2.3.4.so) Expected Results: Document should be saved as docbook xml. Additional info: This is with libgcj-4.0.0-0.40
Where does XSLTransformer come from? And how is it compiled? Ordinarily this kind of problem is the result of a gcj bug. In particular, "gcj -C" doesn't create accessor methods when there are cross-class private member references (which is valid when the two classes share a common top-level enclosing class). Instead, gcj emits a direct reference, which the VM rejects. One workaround is to compile with ecj instead. Another is to make the private member package-private instead; this is actually somewhat better since it avoids an accessor method.
That gives me some info to work with
caolanm->tromey: changing the accessor works. Is there an upstream gcj bug I can cc myself to so to know when I can revert the patch I've added to work around this ?
The upstream accessor bug is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870