Bug 820554 - [fix available] Java functionality broken with gcj
Summary: [fix available] Java functionality broken with gcj
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libreoffice
Version: 6.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Stephan Bergmann
QA Contact: Desktop QE
Depends On:
Blocks: 960054
TreeView+ depends on / blocked
Reported: 2012-05-10 11:42 UTC by Jiri Koten
Modified: 2013-11-21 09:59 UTC (History)
4 users (show)

Fixed In Version: libreoffice-
Doc Type: Bug Fix
Doc Text:
Cause: The linked flag --enable-new-dtags was added to allow certain types of built time regression tests to function. Consequence: At run time gcj's System.loadLibrary failed to search the right location although OpenJDK was unaffected. Fix: Remove --enable-new-dtags and execute tests differently. Result: Java functionality via gcj works again.
Clone Of:
Last Closed: 2013-11-21 09:59:32 UTC
Target Upstream Version:

Attachments (Terms of Use)
Full debug log (273.38 KB, text/plain)
2013-09-06 14:45 UTC, Jiri Koten
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1594 0 normal SHIPPED_LIVE libreoffice bug fix and enhancement update 2013-11-20 22:04:20 UTC

Description Jiri Koten 2012-05-10 11:42:15 UTC
Description of problem:
Running smoketest on ppc64 fails, probably because there is only available java-1.6.0-ibm, java-1.5.0-gcj. Tried both of them. 

Test name: N12_GLOBAL__N_14TestE::test
equality assertion failed
- Expected:
- Actual  :  Base:insert Extensions:services

Failures !!!
Run: 1   Failure total: 1   Failures: 1   Errors: 0

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. build the LO (rpmbuild -bc libreoffice.spec
2. run the smoketest; $ source LinuxX86-64Env.Set.sh; cd smoketestoo_native && build --all

Comment 1 David Tardon 2012-05-10 11:57:37 UTC
It evidently works when run from %check. Could you try to run it in the same way, i.e.,


Comment 2 Jiri Koten 2012-05-10 12:54:42 UTC
IIRC the smoketest is run headless during %check. I run it in Xsession or with exported DISPLAY. The failure I get is when it opens smoketestdoc.sxw, which is not run in headless.

Comment 3 Caolan McNamara 2012-05-10 14:47:48 UTC
its not headless vs non-headless, its gcj vs everything else. My understanding is that openjdk is going into RHEL-6.3 (right?) so I wonder if it makes sense to debug this down to find the flaw, which is likely in gcj itself, in the light of that.

Comment 4 Jiri Koten 2012-05-10 17:41:20 UTC
OpenJDK is not available for ppc64/s390x. 

In the first place I want to make sure it's not a bug in LO, in the second place I'd like to be able to run smoketest/subsequenttests as it helps us during regression testing. Both tests run fine on x86. But I understand if that won't be possible because of gcj.

Comment 6 RHEL Program Management 2012-05-14 04:04:55 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 8 Caolan McNamara 2012-05-30 15:40:18 UTC
bug 826609 is related somehow I bet

Comment 9 Caolan McNamara 2012-07-25 11:04:29 UTC
http://cgit.freedesktop.org/libreoffice/core/commit/?id=962c7209b6f8b708d0b9337cbe5072aa52cda1bb is likely another part of the puzzle

Comment 10 Stephan Bergmann 2012-11-02 10:58:42 UTC
This is indeed only related to PPC64 in so far as there is only gcj and no OpenJDK there; the problem is related to gcj irrespective of architecture.  The problem is unrelated to running smoketest headless or not (and that %check succeeds is because it unsets SOLAR_JAVA for rhel<7, so skips the failing extension tests within smoketest).

What happens is the following:

* bridges/source/jni_uno/java/com/sun/star/bridges/jni_uno/JNI_info_holder.java (in java_uno.jar) calls NativeLibraryLoader to load libjava_uno.so (located in LO's ure/lib dir).

* jurt/com/sun/star/lib/util/NativeLibraryLoader.java first tries to load the lib via "loader.getResource(name)" (in getResource; the loader is the UnoClassLoader, at least because it explicitly includes java_uno.jar in its URL list, see the "TODO get rid of it here" in ridljar/source/unoloader/com/sun/star/lib/unoloader/UnoClassLoader.java).  For some reason, that succeeds with OpenJDK (at least verified with java-1.7.0-openjdk- but not with gcj, where NativeLibraryLoader.getResource returns null, so that NativeLibraryLoader.loadLibrary tries "System.loadLibrary(libname)" as a last resort.

* What that "System.loadLibrary(libname)" effectively results in is a dlopen("libjava_uno.so") from cgj's libjvm.so.

* Due to <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dda5eaa8c0ddfecaaf29e75f2412f7182b9c5744> "Use DT_RUNPATH over DT_RPATH" LO 3.4 soffice.bin (and uno.bin) have both RPATH and RUNPATH settings.  This causes the above dlopen to not consider the executable's RPATH (which is by design, as RUNPATH is also specified) nor RUNPATH.  Whether the latter is a bug or a feature is still not entirely clear to me, cf. <http://sourceware.org/ml/libc-help/2012-11/msg00000.html> "How executable's RPATH/RUNPATH affects .so's dlopen."

* With the change of LO's build system from dmake to GNU Make, the above commit is becoming irrelevant (in converted modules, unit tests always pick up libraries from solver, anyway) and only affects modules that have not yet been reverted.  Therefore, in LO 3.5.7 soffice.bin no longer has a RUNPATH (but uno.bin still has), and in LO 3.6.3 both soffice.bin and uno.bin no longer have a RUNPATH in addition to RPATH.

* This implies that at least starting with LO 3.6.3, the smoketest should also work with gcj, and thus on PPC64.  (I verified it by manually rebuilding soffice.bin and uno.bin with the above commit's --enable-new-dtags switches temporarily removed, and then successfully running the second step of the recipe in the original description.)  It also implies that various Java-related functionality in RHEL 6's LO 3.4 is broken when using gcj, irrespective of architecture (I updated the summary accordingly).

Irrespective of whether or not this is boils down to a glibc bug (and I hope to get that clarified soon, see the mailing list link above), a fix would be to revert the above commit (as it effectively only affects rebuilds, so is not needed in a from-scratch rpmbuild anyway).

Comment 11 Caolan McNamara 2012-11-02 12:49:49 UTC
grrr, law of unexpected side effects. Either way its fixable, so I'll set dev-ack+

Comment 17 Jiri Koten 2013-09-06 14:44:06 UTC
Smoketest failed on ppc64.

[Java framework] The JRE specified by the bootstrap variable UNO_JAVA_JFW_JREHOME  or  UNO_JAVA_JFW_ENV_JREHOME  could not be recognized. Check the values and make sure that you use a plug-in library that can recognize that JRE.
warn:legacy.osl:4455:5:/home/test/rpmbuild/BUILD/libreoffice- [Java framework] The JRE specified by the bootstrap variable UNO_JAVA_JFW_JREHOME  or  UNO_JAVA_JFW_ENV_JREHOME  could not be recognized. Check the values and make sure that you use a plug-in library that can recognize that JRE.
javaldx failed! 
Warning: failed to read path from javaldx

Exited with code '0'
Test name: N12_GLOBAL__N_14TestE::test
equality assertion failed
- Expected: 
- Actual  :  Extensions:services(Extension SmokeTestCommandEnvironment (impleme
nted in Java))

Failures !!!
Run: 1   Failure total: 1   Failures: 1   Errors: 0

Comment 18 Jiri Koten 2013-09-06 14:45:28 UTC
Created attachment 794785 [details]
Full debug log

Comment 19 Stephan Bergmann 2013-09-09 14:07:17 UTC
(In reply to Jiri Koten from comment #17)
Jiri, with what command line exactly did you execute the smoketest for libreoffice-

Comment 20 Jiri Koten 2013-09-09 14:16:31 UTC
I ran 'make check' and after fail I reran with 'make smoketest.subsequentcheck'

Comment 21 Stephan Bergmann 2013-09-13 11:05:04 UTC
You need to set the environment variable JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 (as is done in the---commented out---%check section of libreoffice.spec) to work around bug 1007803 when using LibreOffice with gcj and no $DISPLAY.

Comment 23 Jiri Koten 2013-09-27 09:42:24 UTC
Confirmed the workaround, smoketest passed.

Comment 25 errata-xmlrpc 2013-11-21 09:59:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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