Bug 150650 - [OOo][gcj] calling static methods of a class which references unavailable dependancies
[OOo][gcj] calling static methods of a class which references unavailable dep...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
i386 Linux
low Severity low
: ---
: ---
Assigned To: Tom Tromey
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-09 07:31 EST by Caolan McNamara
Modified: 2014-08-11 01:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-28 03:58:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
java that fails at runtime (10.38 KB, text/x-java)
2005-03-09 07:31 EST, Caolan McNamara
no flags Details
java that succeeds at runtime (10.30 KB, application/octet-stream)
2005-03-09 07:32 EST, Caolan McNamara
no flags Details
failure jar (53.24 KB, application/x-jar)
2005-03-09 07:32 EST, Caolan McNamara
no flags Details
miserable hack of a patch I'm using to workaround for now (17.72 KB, patch)
2005-03-09 07:33 EST, Caolan McNamara
no flags Details | Diff

  None (edit)
Description Caolan McNamara 2005-03-09 07:31:06 EST
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:
Comment 1 Caolan McNamara 2005-03-09 07:31:45 EST
Created attachment 111805 [details]
java that fails at runtime
Comment 2 Caolan McNamara 2005-03-09 07:32:15 EST
Created attachment 111806 [details]
java that succeeds at runtime
Comment 3 Caolan McNamara 2005-03-09 07:32:36 EST
Created attachment 111807 [details]
failure jar
Comment 4 Caolan McNamara 2005-03-09 07:33:05 EST
Created attachment 111808 [details]
miserable hack of a patch I'm using to workaround for now
Comment 5 Tom Tromey 2005-03-10 10:59:47 EST
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.
Comment 6 Caolan McNamara 2005-03-10 11:14:20 EST
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.
Comment 7 Caolan McNamara 2005-03-31 07:30:07 EST
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
Comment 8 Tom Tromey 2005-03-31 11:27:12 EST
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

Comment 9 Caolan McNamara 2005-03-31 12:28:56 EST
WONTFIX is fine by me now that I know what's going on
Comment 10 Thomas Fitzsimmons 2006-02-03 16:36:07 EST
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.
Comment 11 Caolan McNamara 2006-02-06 04:28:21 EST
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.
Comment 12 Tom Tromey 2006-09-27 14:05:58 EDT
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.
Comment 13 Caolan McNamara 2006-09-28 03:58:23 EDT
It's a curse to test, especially as I worked around this in upstream as well.
Let's just close it out.

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