Using OSX Yosemite (10.10) LO master own build 64bit Java 1.8.0_25 Trying to open a report that was previously created and ran correctly no longer opens, throws following error : SQL Status: S1000 An error occurred while creating the report. [jni_uno bridge error] UNO calling Java method execute: [map_to_uno():any] UNO type not found: org.libreoffice.report.ReportExecutionException java stack trace: The report contains three fields in the detail section, no formulae, no sorting, no grouping, no header or footer
@Stephan : you're our Java UNO expert I believe, any idea ?
More background : Mysqldb instance on LAN mysql native C++ connector Report is Writer document Fields in report : TINYINT, VARCHAR(15), VARCHAR(40)
Two other, different, reports in the same ODB file open fine
Just noticed that attempting to open same report in LO 4322 also fails with different error : Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff] There are no timestamps in report !! The timestamp field is in the underlying table, and the table itself can be opened just fine.
Table definition CREATE TABLE `action_type` ( `type` varchar(15) NOT NULL DEFAULT '', `comments` varchar(40) DEFAULT NULL, `action_type_id` tinyint(3) unsigned NOT NULL AUTO_INCREMENT, `chg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`action_type_id`) ) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
Sample data : select * from action_type; +-------------+----------------------------------+----------------+---------------------+ | type | comments | action_type_id | chg_date | +-------------+----------------------------------+----------------+---------------------+ | A.94(3) EPC | Normal Examining Division action | 1 | 0000-00-00 00:00:00 | | R.71(3) EPC | Intention to grant communication | 2 | 0000-00-00 00:00:00 | | R.51(6) EPC | Notice of grant communication | 3 | 2013-01-10 17:15:00 | | A.121 EPC | Further processing | 4 | 2013-01-10 17:56:28 | +-------------+----------------------------------+----------------+---------------------+ 4 rows in set (0,00 sec)
Hmm, methinks it could be mysql's "null" timestamp values which are the root cause
I managed to a little more info in the attached screenshot, by trying to create a totally new report based on a table that had timestamps, but without including the ts field in the report.
Created attachment 108062 [details] UNO JNI error
Confirmed on separate OSX machine.
Possibly linked to bug 71027 ?
If I try the same basic report in LO 4322 with the mysql jdbc connector, once again not including timestamp fields in the report, I get yet another completely different error : You have an error in your SQL syntax, check the manual that corresponds to your mysql server version for the right syntax to use near 'OPTION SQL_SELECT_LIMIT=DEFAULT' at line 1 Where is this option being set ?
(In reply to Alex Thurgood from comment #12) > If I try the same basic report in LO 4322 with the mysql jdbc connector, > once again not including timestamp fields in the report, I get yet another > completely different error : > > You have an error in your SQL syntax, check the manual that corresponds to > your mysql server version for the right syntax to use near > 'OPTION SQL_SELECT_LIMIT=DEFAULT' at line 1 > > Where is this option being set ? Mysql jdbc connector 5.1.31
(In reply to Alex Thurgood from comment #9) > Created attachment 108062 [details] > UNO JNI error The immediate error is that the non-UNO Java type org.libreoffice.report.ReportExecutionException shall be transported as the value of a UNO Any. But that is likely only the consequence of another error, which causes throwing such an org.libreoffice.report.ReportExecutionException somewhere in the reportbuilder/java/org/libreoffice/report/ code in the first place, for reasons yet unknown.
Could you attach a reproducer + dump of MySQL database?
Following Lionel's comment, I put it as NEEDINFO.
Adding self to CC if not already on
Created attachment 112594 [details] sql dump Enclosing sqldump
Steps to reproduce : 1) Create ODB file using mysql native connector extension to bind to database. 2) Open ODB file 3) Select Reports 4) Choose Use wizardto create report 5) In report wizard step 1, select table action_type from dropdown list 6) Then add fields type, comments, action_type_id and click Next 7) In step 2, click Next 8) In steps 3, 4 and 5 click Next without changing anything 9) In step 6, click on Finish An error message occurs. "The document ipdatabase.action_type2 could notbe opened." A whole load of JNI errors with a Java stack trace, which I can't copy appears in the msgbox. I will try and find this in the console logs. Click on Ok and the error message disappears. The report is saved nonetheless, but any attempt to execute it leads to the [jni_uno bridge error] UNO calling Java method execute: [map_to_uno():any] UNO type not found: org.libreoffice.report.ReportExecutionException java stack trace: error message Alex
Console is showing possibly unrelated message with master 4500alpha dynamic_cast error 2: One or more of the following type_info's has hidden visibility. They should all have public visibility. 7SdrView, 12SdrPaintView, 10FmFormView.
Created attachment 112597 [details] full bt Enclosing full bt
Tested today on Version: 4.5.0.0.alpha0+ Build ID: 15db0307fe6429238be72612cccd4a1df5e1e97c Locale: fr_
bt=> NEW Noel: I noticed this: java.lang.NullPointerException at org.pentaho.reporting.libraries.base.boot.PackageManager.containsModule(PackageManager.java:369) at org.pentaho.reporting.libraries.base.boot.PackageManager.loadModule(PackageManager.java:436) at org.pentaho.reporting.libraries.base.boot.PackageManager.addModule(PackageManager.java:330) at org.pentaho.reporting.libraries.base.boot.PackageManager.load(PackageManager.java:199) at org.jfree.report.JFreeReportBoot.performBoot(Unknown Source) at org.pentaho.reporting.libraries.base.boot.AbstractBoot.start(AbstractBoot.java:197) at org.libreoffice.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:34) at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:318) at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:212) Thought you might be interested in this one since I wonder if it could be related to the cleaning of the java part (again just a guess for the moment, I'll try to take a look tonight or tomorrow)
(In reply to Alex Thurgood from comment #21) > Created attachment 112597 [details] > full bt why did you continue upon the first few JVM-induced SIGSEGVs and then decided to show the backtraces upon the next one? did that one look any different? note that the JVM routinely raises and handles SIGSEGVs (not that I'm sure an soffice.bin backtrace would be of much help here anyway; but I for one cannot look into this as I'm already lost at step 1 of the reproducer in comment 19)
(In reply to Stephan Bergmann from comment #24) > (In reply to Alex Thurgood from comment #21) > > Created attachment 112597 [details] > > full bt > > why did you continue upon the first few JVM-induced SIGSEGVs and then > decided to show the backtraces upon the next one? did that one look any > different? note that the JVM routinely raises and handles SIGSEGVs > > (not that I'm sure an soffice.bin backtrace would be of much help here > anyway; but I for one cannot look into this as I'm already lost at step 1 of > the reproducer in comment 19) Hi Stephan, the reason I continued was to just to check whether or not LO could recover from the SIGSEGV of the JVM as sometimes with debug builds this happens. Additionally, the hex values of the frame were slightly different between the first and second times Process 31063 stopped * thread #1: tid = 0x1ec6d5, 0x000000012e3658f5, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV frame #0: 0x000000012e3658f5 -> 0x12e3658f5: movl 0xc(%rdx), %r9d then Process 31063 stopped * thread #1: tid = 0x1ec6d5, 0x000000012e16fa6e, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV frame #0: 0x000000012e16fa6e -> 0x12e16fa6e: movl 0x8(%rcx), %edx
(In reply to Stephan Bergmann from comment #24) > (not that I'm sure an soffice.bin backtrace would be of much help here > anyway; but I for one cannot look into this as I'm already lost at step 1 of > the reproducer in comment 19) You need to have LO with the mysql native connector C++ extension installed. Then you need to import the sql dump into a mysql db instance. This will create a database called ipdatabase containing one table, action_type and the sample data. After that create your ODB file, using the wizard to connect to the database via the connector extension : Start LO Choose New Database DB creation wizard starts. Connect to existing database - choose mysql from the dropdown - Next Choose connect directly (third choice in list, if you also have odbc and jdbc connectors set up) - Next Fill in your database name and host connection address and port if different from the default (127.0.0.1/3306) - Next Enter User name / password if necessary for your mysql connection - test connection Finish, then save your ODB file. Open ODB file and follow previous instructions
Testing on LO 4.1 gives the same error as in comment 4. Probably linked to the changes made to timestamp definitions (inclusion of nanosecond handling) during 4.1 development ?
The problem is indeed most probably the "all zeros" dates from MySQL, which are not valid values in SQL. Basing the report on a query that does not include the chg_date column works around the problem.
With what version did it use to work?
(In reply to Alex Thurgood from comment #4) > Just noticed that attempting to open same report in LO 4322 also fails with > different error : > > > Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff] > > There are no timestamps in report !! The timestamp field is in the > underlying table, and the table itself can be opened just fine. This error comes from Java. Since displaying the table does not use Java, it does not encounter this particular problem. I guess that Java refuses to handle date "0000-00-00 00:00:00".
So... The hiding of the real error behind "ReportExecutionException" is indeed from Noel's commit commit 9341bf3dc38b2cc117ffbe12ff057511ed6e046d Author: Noel Grandin <noel@peralex.com> Date: Thu Oct 16 12:19:14 2014 +0200 java: when rethrowing, store the original exception Change-Id: I34ce000c48d2d79bfec854c8dd55d12f2bee29c7 Noel, you cannot stick an arbitrary Java exception into a UNO exception, only a UNO exception... It will not pass the UNO barrier to C++. Please review your whole commit in this light. If you want to make that kind of throwing more useful, you can do something like: Writer result = new StringWriter(); PrintWriter printWriter = new PrintWriter(result); e.printStackTrace(printWriter); throw new com.sun.star.lang.WrappedTargetException(e.toString() + '\n' + result.toString(), this, null)
So, I confirmed that this error comes when trying to convert a "all zeros" timestamp (that ultimately comes from MySQL) to a Java timestamp. Java does not accept "0000-00-00 00:00:00.000000000" as a valid timestamp. Seeing the history of the code, I doubt it ever worked.
(In reply to Lionel Elie Mamane from comment #32) > So, I confirmed that this error comes when trying to convert a "all zeros" > timestamp (that ultimately comes from MySQL) to a Java timestamp. Java does > not accept "0000-00-00 00:00:00.000000000" as a valid timestamp. > > Seeing the history of the code, I doubt it ever worked. Since official LibreOffice builds don't include the native MySQL driver, I cannot easily check that. Anyway, what could we do about this? I only see silently replacing MySQL zero dates with NULL. That's what the ODBC driver does. But the JDBC driver does it only optionally (and not by default, see zeroDateTimeBehavior=convertToNull). So.. <shrug> haven't decided what to do yet.
Created attachment 112603 [details] patch to transform zero dates to NULL Here's a patch to implement replacing zero dates by NULL unconditionally. If someone wants to add all the code and UI to make it optional, then we can do it. Else, I'll just consider it as a MySQL bug / misfeature.
(In reply to Lionel Elie Mamane from comment #31) > Noel, you cannot stick an arbitrary Java exception into a UNO exception, > only a UNO exception... It will not pass the UNO barrier to C++. Please > review your whole commit in this light. > > If you want to make that kind of throwing more useful, you can do something > like: > > Writer result = new StringWriter(); > PrintWriter printWriter = new PrintWriter(result); > e.printStackTrace(printWriter); > throw new > com.sun.star.lang.WrappedTargetException(e.toString() + '\n' + > result.toString(), this, null) You can also separate the case of catching a UNO exception, and in this case store the original exception, from the case of an arbitrary Java exception, and in this case do as above.
(In reply to Lionel Elie Mamane from comment #29) > With what version did it use to work? That is a good question, unfortunately, the shift to all 64bit program stack, including the connector extension, means that I can no longer test.
(In reply to Alex Thurgood from comment #36) > (In reply to Lionel Elie Mamane from comment #29) > > With what version did it use to work? > > That is a good question, unfortunately, the shift to all 64bit program > stack, including the connector extension, means that I can no longer test. All I know is that it did, but that it would have been with an earlier version of LO (3.x ?) 32bit, native connector 1.01 ?, plus 32bit Java and 32 bit mysql - too many variables !
(In reply to Lionel Elie Mamane from comment #34) > Created attachment 112603 [details] [review] > patch to transform zero dates to NULL > > Here's a patch to implement replacing zero dates by NULL unconditionally. If > someone wants to add all the code and UI to make it optional, then we can do > it. > > Else, I'll just consider it as a MySQL bug / misfeature. This got me wondering how other Java report builders deal with this problem. After all, they interface with a wide range of different dbs with varying timestamp definitions. Will try and have a trawl to see what I can dig up.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=01fb1701c8a59dd023604492a117ea1a6cffcee9 Related fdo#85190: Don't dress arbitrary Java Throwables as UNO Any values It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #39) > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=01fb1701c8a59dd023604492a117ea1a6cffcee9 > > Related fdo#85190: Don't dress arbitrary Java Throwables as UNO Any values ...addresses the sub-thread of comment 14, comment 31, comment 35
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5ff2e409d450d53ab0bed7cdc3de18841c5c7fb&h=libreoffice-4-4 Related fdo#85190: Don't dress arbitrary Java Throwables as UNO Any values It will be available in 4.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Stephan Bergmann from comment #40) > (In reply to Commit Notification from comment #39) > > http://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=01fb1701c8a59dd023604492a117ea1a6cffcee9 > > > > Related fdo#85190: Don't dress arbitrary Java Throwables as UNO Any values > > ...addresses the sub-thread of comment 14, comment 31, comment 35 Thanks. The catch (java.lang.IncompatibleClassChangeError e2) { LOGGER.error("Detected an IncompatibleClassChangeError"); throw new com.sun.star.lang.WrappedTargetException(e2, "caught a " + e2.getClass().getName(), this, new com.sun.star.uno.Exception(e2.getLocalizedMessage())); } to me looks like it will not work, trying to pass a java.lang.IncompatibleClassChangeError through UNO. Anyway, I improved the message / throwing: http://cgit.freedesktop.org/libreoffice/core/commit/?id=f4a2cff16ea546e7d0a135d4b061a65e783ab422 Feel free to cherry-pick to libreoffice-4-4.
(In reply to Lionel Elie Mamane from comment #42) > catch (java.lang.IncompatibleClassChangeError e2) > { > LOGGER.error("Detected an IncompatibleClassChangeError"); > throw new com.sun.star.lang.WrappedTargetException(e2, "caught a " + > e2.getClass().getName(), this, new > com.sun.star.uno.Exception(e2.getLocalizedMessage())); > } > > to me looks like it will not work, trying to pass a > java.lang.IncompatibleClassChangeError through UNO. No. In UNO exception ctors, the optional leading Throwable argument ('e2') is only used to pass it as 'cause' argument into the underlying java.lang.Throwable ctor; it is not "passed through UNO." What was problematic about Noel's commit was that UNO exception css.lang.WrappedTargetException takes a UNO Any argument containing a UNO exception value, and /that/ must not be an arbitrary Java non-UNO exception (was erroneously 'e2', is now 'new com.sun.star.uno.Exception(...)'). > Anyway, I improved the message / throwing: > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=f4a2cff16ea546e7d0a135d4b061a65e783ab422 That commit needlessly removes passing in the 'cause' argument. Please revisit.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a358461a5c266bec5148f89e7fbb4b4d7d0ce91e&h=libreoffice-4-4-0 Related fdo#85190: Don't dress arbitrary Java Throwables as UNO Any values It will be available in 4.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Alex Thurgood from comment #20) > Console is showing possibly unrelated message with master 4500alpha > > dynamic_cast error 2: One or more of the following type_info's has hidden > visibility. They should all have public visibility. 7SdrView, > 12SdrPaintView, 10FmFormView. (Indeed unrelated, and incidentally addressed now with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4f6b26b5a1a78fecfa95ec2eb7ac8b80495d8aa> "SAL_DLLPUBLIC_RTTI for proper RTTI visibility for LLVM.")
(In reply to Stephan Bergmann from comment #43) > (In reply to Lionel Elie Mamane from comment #42) > > catch (java.lang.IncompatibleClassChangeError e2) > > { > > LOGGER.error("Detected an IncompatibleClassChangeError"); > > throw new com.sun.star.lang.WrappedTargetException(e2, "caught a " + > > e2.getClass().getName(), this, new > > com.sun.star.uno.Exception(e2.getLocalizedMessage())); > > } > > > > to me looks like it will not work, trying to pass a > > java.lang.IncompatibleClassChangeError through UNO. > > No. In UNO exception ctors, the optional leading Throwable argument ('e2') > is only used to pass it as 'cause' argument into the underlying > java.lang.Throwable ctor; it is not "passed through UNO." So it is thrown away when the Java exception is caught by the Java UNO bridge, and the latter throws a UNO exception to whatever called that Java code through UNO? I see. Thanks for the explanation. >> Anyway, I improved the message / throwing: >> http://cgit.freedesktop.org/libreoffice/core/commit/ >> ?id=f4a2cff16ea546e7d0a135d4b061a65e783ab422 > That commit needlessly removes passing in the 'cause' argument. Please > revisit. Readded in http://cgit.freedesktop.org/libreoffice/core/commit/?cc376d87859a478b6cab348f0c96ea9fa7fe7a9a