Description: Attempting to open an extant report gives the splash: "Loading component library <file:///usr/lib/libreoffice/program/-librptlo.so> failed. ./cppuhelper/source/shlib.cxx:311 These reports functioned normally before the system upgrade from buster to bullseye. Tried download and install of 7.3x from LibreOffice.org. Same result. there is a file at /usr/lib/libreoffice/program/librptlo.so. Perhaps the hyphen is a typo in source? Steps to Reproduce: 1.Open existing Base database file. 2.Attempt to print existing report. Actual Results: Error splash detailed in Description above. Expected Results: Generation of report. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.3.1.3 / LibreOffice Community Build ID: 30(Build:3) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.utf8); UI: en-US Debian package version: 1:7.3.1-1~bpo11+1 Calc: threaded
Could you try to uninstall the deb installed manually + LO from Debian repo with "purge" option ? Then rename your LO directory profile (see https://wiki.documentfoundation.org/QA/FirstSteps#Corrupted_user_profile) and install LO again from Debian repo.
Thank you for your help, Julian. I had done, per the bug reporting guidelines, but I re-did and also did a complete purge of all references to libreoffice via 'apt' before re-installing the distro (bullseye) version. This does give me a more prolix error splash when I attempt to call the report: -------------------------------- [jni_uno bridge error] UNO calling Java method execute: non-UNO exception occurred: java.lang.UnsupportedClassVersionError: org/jfree/report/JFreeReportBoot has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 java stack trace: java.lang.UnsupportedClassVersionError: org/jfree/report/JFreeReportBoot has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:817) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.libreoffice.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:34) at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:355) at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:239) ./bridges/source/jni_uno/jni_uno2java.cxx:785
What's your current Java version ? (just type this on console: "java --version")
Sorry. Meant to include that. More coffee is indicated. openjdk 11.0.14.1 2022-02-08 LTS OpenJDK Runtime Environment Zulu11.54+25-CA (build 11.0.14.1+1-LTS) OpenJDK 64-Bit Server VM Zulu11.54+25-CA (build 11.0.14.1+1-LTS, mixed mode)
Ok I got the same Java version. Just for the test, could you try to create a brand new file with just a table and a report? The goal is to know if the pb is triggered because of installed components on your machine and it's specific to this odb file. (also, I suppose you don't have Apache OpenOffice in // or other LO packages via flatpack or anything).
Creating a new "database", i get a similar splash. I am running Apache2 web services, but no OO pkgs. The Base database table is a tab in an .ods spreadsheet in both the original and the new test instance. ... Different spreadsheets, not the same one. Both display fine if opened from the Tables section of the Base program. ------------------------------------ [jni_uno bridge error] UNO calling Java method execute: non-UNO exception occurred: java.lang.UnsupportedClassVersionError: org/jfree/report/JFreeReportBoot java stack trace: java.lang.UnsupportedClassVersionError: org/jfree/report/JFreeReportBoot at org.libreoffice.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:34) at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:355) at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:239) ./bridges/source/jni_uno/jni_uno2java.cxx:785
[Automated Action] NeedInfo-To-Unconfirmed
Unconfirmed?? I assure you, it is happening. Base is unusable for my purposes, after years of reliable performance. I will be glad to supply more info, if directed and requested. I assume -you- have tried to generate a report with this release. What was the result??
Current version after purge, installed from Debian Bullseye packages. Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: x11 Locale: en-US (en_US.utf8); UI: en-US Debian package version: 1:7.0.4-4+deb11u1 Calc: threaded
(In reply to twag@snarkboojum.com from comment #8) > Unconfirmed?? I assure you, it is happening. Base is unusable for my > purposes, after years of reliable performance. > > I will be glad to supply more info, if directed and requested. I assume > -you- have tried to generate a report with this release. What was the > result?? I had put it at NEEDINFO, you responded so an automatic mechanism had put it back to UNCONFIRMED. This status is the right one since someone must confirm this by reproducing it. About the bug itself, would it be possible you attach a file so we can reproduce this? (of course sanitize it if needed, see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission). If not HSQLDB, we'd need the type of database and an SQL script to create the tables and data to be able to reproduce this.
Created attachment 178880 [details] Spreadsheet source data for example Base database.
Created attachment 178881 [details] Base database example illustrating report failure
Thanks again. I should have looked more closely at the Status descriptions. Here are two files: a spreadsheet exemplar of a data source (auto service records) The Base database file using the spreadsheet a source. It contains a simple query, called by a report which fails. Attempting to open the report should give the error splash. NB: I updated the version info on the bug report to agree with the current installed version after the comprehensive purge actions detailed above.
Created attachment 178883 [details] screenshot of the report On pc Debian x86-64 with LO Debian package 7.3.1.3, I could open the report (after having modified datasource location obviously), see screenshot. Remark :With master sources updated today with enable-dbgutil, I got a crash when trying to open the report.
Noting the java references in the error splash. Here is the report from update-alternatives: There are 5 choices for the alternative java (providing /usr/bin/java). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/lib/jvm/zulu11/bin/java 2115401 auto mode 1 /opt/java-oracle/jdk1.7.0/bin/java 20000 manual mode 2 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode 3 /usr/lib/jvm/java-8-oracle/jre/bin/java 1081 manual mode 4 /usr/lib/jvm/zulu11/bin/java 2115401 manual mode 5 /usr/lib/jvm/zulu8/jre/bin/java 1806001 manual mode The Zulu java is required by my online trading software. But, could it's selection in auto mode be problematic for LO??
You can give a try to: 2 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode If the report opens, you'll have your answer.
No joy. Same result. Also tried java 8. Worth a shot. Sorry if it was a red herring.
Robert/Alex: any idea here what could be the root cause?
Have downloaded the attached Calc file and the database file. Could execute the report without any problem. Tested with LO 7.3.1.3 on OpenSUSE 15.3 64bit rpm Linux.
Before system upgrade, which LO version did you use? LO 7.2.5, a version from 7.1 branch ?
(In reply to twag@snarkboojum.com from comment #2) > [jni_uno bridge error] UNO calling Java method execute: non-UNO exception > occurred: java.lang.UnsupportedClassVersionError: > org/jfree/report/JFreeReportBoot has been compiled by a more recent version > of the Java Runtime (class file version 55.0), this version of the Java > Runtime only recognizes class file versions up to 52.0 This message appears to be indicating that the JFreereport component of the reportbuilder code was built using a more recent JDK than the one on the OP's system. What this might mean in practice is that the OP has an older version, or bits thereof, of Java still lying around in their Java system path, and the reportbuilder code is picking up on those bits and then failing due to the mismatch in expected version. From comment 16, I see that there are multiple JDK environments installed, I would put money on one of them being the culprit. I would certainly try isolating the zulu stuff, not even sure that they are correctly recognized/instanciated by LO, and hte JREs are pretty much useless these days with current production releases of LO (but are possibly still relevant for 7.0.x releases). I don't know which JDK the Debian maintainer built the JFreeport components against for Buster, so that's probably where I would start to at least try and have a system that corresponded to those requirements.
FWIW, testing on macOS Arm M1 processor Macbook, and Version: 7.2.6.2 / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded I can open the test ODB file and report contained therein without error. My JDK is Oracle jdk-17_x64 (Intel) when using the Intel version of LO, and Java version from terminal : java --version openjdk 17-ea 2021-09-14 OpenJDK Runtime Environment Zulu17+63-CA (build 17-ea+27) OpenJDK 64-Bit Server VM Zulu17+63-CA (build 17-ea+27, mixed mode, sharing)
Same bug, only with build of OpenSUSE: bug 148841. Please try the packages direct from LO, not packages from your distribution.
It's a bit weird that different distribs (OpenSuse for tdf#148841, Mageia for tdf#148042, Debian here) have a bug exactly on the same subject. Rene: since this one concerns Debian, any thoughts here?