Bug 147947 - After upgrade to Debian Bullseye, LO Base Reports fail to open/print.
Summary: After upgrade to Debian Bullseye, LO Base Reports fail to open/print.
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-12 19:50 UTC by twag@snarkboojum.com
Modified: 2022-05-21 07:23 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Spreadsheet source data for example Base database. (173.25 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-03-14 17:28 UTC, twag@snarkboojum.com
Details
Base database example illustrating report failure (6.27 KB, application/vnd.oasis.opendocument.database)
2022-03-14 17:29 UTC, twag@snarkboojum.com
Details
screenshot of the report (168.63 KB, image/png)
2022-03-14 18:09 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description twag@snarkboojum.com 2022-03-12 19:50:14 UTC
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
Comment 1 Julien Nabet 2022-03-13 10:27:23 UTC
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.
Comment 2 twag@snarkboojum.com 2022-03-13 17:03:10 UTC
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
Comment 3 Julien Nabet 2022-03-13 17:13:56 UTC
What's your current Java version ? (just type this on console: "java --version")
Comment 4 twag@snarkboojum.com 2022-03-13 17:19:02 UTC
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)
Comment 5 Julien Nabet 2022-03-13 17:55:29 UTC
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).
Comment 6 twag@snarkboojum.com 2022-03-13 22:35:11 UTC
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
Comment 7 QA Administrators 2022-03-14 03:35:15 UTC Comment hidden (obsolete)
Comment 8 twag@snarkboojum.com 2022-03-14 03:45:19 UTC
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??
Comment 9 twag@snarkboojum.com 2022-03-14 17:09:14 UTC
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
Comment 10 Julien Nabet 2022-03-14 17:15:11 UTC
(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.
Comment 11 twag@snarkboojum.com 2022-03-14 17:28:04 UTC
Created attachment 178880 [details]
Spreadsheet source data for example Base database.
Comment 12 twag@snarkboojum.com 2022-03-14 17:29:24 UTC
Created attachment 178881 [details]
Base database example illustrating report failure
Comment 13 twag@snarkboojum.com 2022-03-14 17:34:33 UTC
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.
Comment 14 twag@snarkboojum.com 2022-03-14 17:35:49 UTC Comment hidden (obsolete)
Comment 15 Julien Nabet 2022-03-14 18:09:28 UTC
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.
Comment 16 twag@snarkboojum.com 2022-03-15 19:44:18 UTC
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??
Comment 17 Julien Nabet 2022-03-15 19:51:48 UTC
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.
Comment 18 twag@snarkboojum.com 2022-03-15 20:01:14 UTC
No joy. Same result.  Also tried java 8.

Worth a shot.  Sorry if it was a red herring.
Comment 19 Julien Nabet 2022-03-15 20:09:49 UTC
Robert/Alex: any idea here what could be the root cause?
Comment 20 Robert Großkopf 2022-03-16 07:13:00 UTC
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.
Comment 21 Julien Nabet 2022-03-17 07:23:51 UTC
Before system upgrade, which LO version did you use? LO 7.2.5, a version from 7.1 branch ?
Comment 22 Alex Thurgood 2022-03-29 09:03:34 UTC
(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.
Comment 23 Alex Thurgood 2022-03-29 09:09:37 UTC
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)
Comment 24 Robert Großkopf 2022-05-20 15:28:03 UTC
Same bug, only with build of OpenSUSE: bug 148841.
Please try the packages direct from LO, not packages from your distribution.
Comment 25 Julien Nabet 2022-05-21 07:23:02 UTC
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?