Red Hat Bugzilla – Bug 150650
[OOo][gcj] calling static methods of a class which references unavailable dependancies
Last modified: 2014-08-11 01:46:26 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220 Description of problem: This is unfortunately a wooley bug report, apologies. The code attached compiles into a jar fine under gcj, OOo's component registration calls __writeRegistryServiceInfo(com.sun.star.registry.XRegistryKey xregistrykey) from a long chain through the jni interface, my problem is that I don't get from... System.err.println("ok here\n"); to.. System.err.println("doesn't get here\n"); during execution. The failure is apparently with... String sClass = ReportWizardImplementation.class.getName(); nothing is thrown to be caught. Strangely on hacking ReportWizardImplementation to remove some unrelated code in the .success varient also attached then it's ok. Attempting to reduce into a smaller standalong example and all is well. Attached is report.jar generated from the above in case that's useful in some way, and the temporary workaround patch I'm using to progress for now :-( Version-Release number of selected component (if applicable): libgcj-4.0.0-0.30 How reproducible: Always Steps to Reproduce: 1. Very tricky Additional info:
Created attachment 111805 [details] java that fails at runtime
Created attachment 111806 [details] java that succeeds at runtime
Created attachment 111807 [details] failure jar
Created attachment 111808 [details] miserable hack of a patch I'm using to workaround for now
How are you running this code? Do you take the .jar and compile it with 'gcj -findirect-dispatch'? Or do you run interpreted? Or ... something else? One thing to note is that the 'foo.class' construct compiles to a synthetic bytecode method (see the 'class$' method in CallReportWizard). In theory this method will properly throw an error on failure. It may be worth debugging into this method. What does happen when you run this? Does the runtime crash? Offhand I don't know why your change to the source would affect this.
compiled just as gcj -C -g -fno-assert -Wno-deprecated to a jar, nothing else done afterwards. It gets called through (a huge c++ chain) CallObjectMethod on some other java object which calls it. I'll try and debug further to see where things go awry.
Ok, I reckon I have it. During registration OOo sets a minimal CLASSPATH, sun's java seems happy with this small classpath which doesn't include "commonwizards.jar" which provides com.sun.star.wizards.common.Properties that is used by the ReportWizardImplmentation mentioned in comment #1. Methods that reference common.Properties aren't used during the critical registration path, on indeed is a ReportWizardImplementation instantiated, only getName and similiar static methods belonging to ReportWizardImplmentation. Sun's java seems to happily run them without complaint, while gcj seems to want to resolve the needs of ReportWizardImplementation when ReportWizardImplmentation.class.getName is called(), and barfs on the missing com.sun.star.wizards.common.Properties. I can work around this by simply add the commonwizards.jar to the OOo registration minimalclasspath
libgcj does tend to link classes more aggressively than some other VMs. Changing this would be tricky, as it would require changes to code generation (AFAICS). Technically I think we are within the bounds of the spec, see the note about lazy linking in the 3rd paragraph here: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#22574
WONTFIX is fine by me now that I know what's going on
Tom tells me that this will be fixed in GCJ 4.2, but that will be post-FC5. I'll leave this report open until then.
Sure if you want, but I upstreamed the necessary registration time classpath stuff to OOo so we don't need this to work at the moment.
If you are set up for it, retry this on FC6. The fixes mentioned in comment #10 should be in the FC6 gcj. If you can't easily test, I say we close this bug. Thanks.
It's a curse to test, especially as I worked around this in upstream as well. Let's just close it out.