Bug 150650 - [OOo][gcj] calling static methods of a class which references unavailable dependancies
Summary: [OOo][gcj] calling static methods of a class which references unavailable dep...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Tom Tromey
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-09 12:31 UTC by Caolan McNamara
Modified: 2014-08-11 05:46 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-28 07:58:23 UTC
Type: ---
Embargoed:


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

Description Caolan McNamara 2005-03-09 12:31:06 UTC
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 12:31:45 UTC
Created attachment 111805 [details]
java that fails at runtime

Comment 2 Caolan McNamara 2005-03-09 12:32:15 UTC
Created attachment 111806 [details]
java that succeeds at runtime

Comment 3 Caolan McNamara 2005-03-09 12:32:36 UTC
Created attachment 111807 [details]
failure jar

Comment 4 Caolan McNamara 2005-03-09 12:33:05 UTC
Created attachment 111808 [details]
miserable hack of a patch I'm using to workaround for now

Comment 5 Tom Tromey 2005-03-10 15:59:47 UTC
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 16:14:20 UTC
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 12:30:07 UTC
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 16:27:12 UTC
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 17:28:56 UTC
WONTFIX is fine by me now that I know what's going on

Comment 10 Thomas Fitzsimmons 2006-02-03 21:36:07 UTC
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 09:28:21 UTC
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 18:05:58 UTC
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 07:58:23 UTC
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.