Bug 85190 - REPORTBUILDER - cannot deal with MySQL bogus '0000-00-00' date and timestamps
Summary: REPORTBUILDER - cannot deal with MySQL bogus '0000-00-00' date and timestamps
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Mac OS X (All)
: highest blocker
Assignee: Not Assigned
URL:
Whiteboard: target:4.4.0
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2014-10-19 09:08 UTC by Alex Thurgood
Modified: 2016-05-30 07:58 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
UNO JNI error (81.84 KB, image/png)
2014-10-19 12:49 UTC, Alex Thurgood
Details
sql dump (1.88 KB, text/plain)
2015-01-21 10:29 UTC, Alex Thurgood
Details
full bt (81.18 KB, text/plain)
2015-01-21 11:02 UTC, Alex Thurgood
Details
patch to transform zero dates to NULL (4.90 KB, patch)
2015-01-21 14:36 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2014-10-19 09:08:55 UTC
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
Comment 1 Alex Thurgood 2014-10-19 09:10:19 UTC
@Stephan : you're our Java UNO expert I believe, any idea ?
Comment 2 Alex Thurgood 2014-10-19 09:21:26 UTC
More background :

Mysqldb instance on LAN

mysql native C++ connector

Report is Writer document
Fields in report : TINYINT, VARCHAR(15), VARCHAR(40)
Comment 3 Alex Thurgood 2014-10-19 09:23:11 UTC
Two other, different, reports in the same ODB file open fine
Comment 4 Alex Thurgood 2014-10-19 09:27:01 UTC
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.
Comment 5 Alex Thurgood 2014-10-19 09:42:35 UTC
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
Comment 6 Alex Thurgood 2014-10-19 09:45:36 UTC
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)
Comment 7 Alex Thurgood 2014-10-19 09:47:09 UTC
Hmm, methinks it could be mysql's "null" timestamp values which are the root cause
Comment 8 Alex Thurgood 2014-10-19 12:49:22 UTC
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.
Comment 9 Alex Thurgood 2014-10-19 12:49:54 UTC
Created attachment 108062 [details]
UNO JNI error
Comment 10 Alex Thurgood 2014-10-19 12:51:31 UTC
Confirmed on separate OSX machine.
Comment 11 Alex Thurgood 2014-10-19 13:05:58 UTC
Possibly linked to bug 71027 ?
Comment 12 Alex Thurgood 2014-10-19 13:59:45 UTC
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 ?
Comment 13 Alex Thurgood 2014-10-19 14:04:21 UTC
(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
Comment 14 Stephan Bergmann 2014-10-20 09:26:12 UTC
(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.
Comment 15 Lionel Elie Mamane 2014-10-24 22:04:55 UTC
Could you attach a reproducer + dump of MySQL database?
Comment 16 Julien Nabet 2014-11-17 19:03:38 UTC
Following Lionel's comment, I put it as NEEDINFO.
Comment 17 Alex Thurgood 2015-01-03 17:41:32 UTC
Adding self to CC if not already on
Comment 18 Alex Thurgood 2015-01-21 10:29:22 UTC
Created attachment 112594 [details]
sql dump

Enclosing sqldump
Comment 19 Alex Thurgood 2015-01-21 10:46:25 UTC
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
Comment 20 Alex Thurgood 2015-01-21 10:50:07 UTC
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.
Comment 21 Alex Thurgood 2015-01-21 11:02:04 UTC
Created attachment 112597 [details]
full bt

Enclosing full bt
Comment 22 Alex Thurgood 2015-01-21 11:04:20 UTC
Tested today on

Version: 4.5.0.0.alpha0+
Build ID: 15db0307fe6429238be72612cccd4a1df5e1e97c
Locale: fr_
Comment 23 Julien Nabet 2015-01-21 11:09:36 UTC
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)
Comment 24 Stephan Bergmann 2015-01-21 11:10:46 UTC
(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)
Comment 25 Alex Thurgood 2015-01-21 11:20:24 UTC
(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
Comment 26 Alex Thurgood 2015-01-21 11:29:13 UTC
(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
Comment 27 Alex Thurgood 2015-01-21 11:34:45 UTC
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 ?
Comment 28 Lionel Elie Mamane 2015-01-21 12:08:41 UTC
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.
Comment 29 Lionel Elie Mamane 2015-01-21 12:09:04 UTC
With what version did it use to work?
Comment 30 Lionel Elie Mamane 2015-01-21 12:12:39 UTC
(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".
Comment 31 Lionel Elie Mamane 2015-01-21 13:51:57 UTC
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)
Comment 32 Lionel Elie Mamane 2015-01-21 14:02:59 UTC
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.
Comment 33 Lionel Elie Mamane 2015-01-21 14:31:48 UTC
(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.
Comment 34 Lionel Elie Mamane 2015-01-21 14:36:24 UTC
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.
Comment 35 Lionel Elie Mamane 2015-01-21 14:46:51 UTC
(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.
Comment 36 Alex Thurgood 2015-01-21 15:30:26 UTC
(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.
Comment 37 Alex Thurgood 2015-01-21 15:35:50 UTC
(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 !
Comment 38 Alex Thurgood 2015-01-21 15:46:40 UTC
(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.
Comment 39 Commit Notification 2015-01-21 16:32:48 UTC
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.
Comment 40 Stephan Bergmann 2015-01-21 16:39:36 UTC
(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
Comment 41 Commit Notification 2015-01-21 16:46:41 UTC
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.
Comment 42 Lionel Elie Mamane 2015-01-21 17:31:23 UTC
(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.
Comment 43 Stephan Bergmann 2015-01-22 07:41:59 UTC
(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.
Comment 44 Commit Notification 2015-01-22 09:16:09 UTC
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.
Comment 45 Stephan Bergmann 2015-01-22 09:22:23 UTC
(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.")
Comment 46 Lionel Elie Mamane 2015-01-22 12:21:16 UTC
(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