Deadlock in HSQLDB

[Stephan Bergmann]

Running JunitTest_dbaccess_complex happened to deadlock the soffice.bin 
process for me once (non-reproducibly), and jstack shows that there is a 
deadlock in HSQLDB Java code in the in-process JVM:

> Found one Java-level deadlock:
> =============================
> "Thread-275584":
>   waiting to lock monitor 0x00002ac4e8004d78 (object 0x00000005e9008720, a org.hsqldb.lib.HsqlTimer$TaskQueue),
>   which is held by "HSQLDB Timer @5749ac52"
> "HSQLDB Timer @5749ac52":
>   waiting to lock monitor 0x00002ac4e8005508 (object 0x00000007959e9bb0, a org.hsqldb.lib.HsqlTimer$Task),
>   which is held by "Thread-275584"
>
> Java stack information for the threads listed above:
> ===================================================
> "Thread-275584":
> 	at org.hsqldb.lib.HsqlTimer$TaskQueue.signalTaskCancelled(HsqlTimer.java:926)
> 	- waiting to lock <0x00000005e9008720> (a org.hsqldb.lib.HsqlTimer$TaskQueue)
> 	at org.hsqldb.lib.HsqlTimer$Task.cancel(HsqlTimer.java:728)
> 	at org.hsqldb.lib.HsqlTimer$Task.setPeriod(HsqlTimer.java:803)
> 	- locked <0x00000007959e9bb0> (a org.hsqldb.lib.HsqlTimer$Task)
> 	at org.hsqldb.lib.HsqlTimer.setPeriod(HsqlTimer.java:428)
> 	at org.hsqldb.scriptio.ScriptWriterBase.setWriteDelay(ScriptWriterBase.java:418)
> 	at org.hsqldb.persist.Log.setWriteDelay(Log.java:529)
> 	at org.hsqldb.persist.Logger.setWriteDelay(Logger.java:386)
> 	- locked <0x00000005e971ad68> (a org.hsqldb.persist.Logger)
> 	at org.hsqldb.DatabaseCommandInterpreter.processSet(DatabaseCommandInterpreter.java:2361)
> 	at org.hsqldb.DatabaseCommandInterpreter.executePart(DatabaseCommandInterpreter.java:308)
> 	at org.hsqldb.DatabaseCommandInterpreter.execute(DatabaseCommandInterpreter.java:170)
> 	at org.hsqldb.Session.sqlExecuteDirectNoPreChecks(Session.java:1037)
> 	- locked <0x00000005e9703c98> (a org.hsqldb.Database)
> 	at org.hsqldb.Session.execute(Session.java:899)
> 	- locked <0x00000005e9703c98> (a org.hsqldb.Database)
> 	at org.hsqldb.jdbc.jdbcStatement.fetchResult(jdbcStatement.java:1581)
> 	at org.hsqldb.jdbc.jdbcStatement.execute(jdbcStatement.java:628)
> "HSQLDB Timer @5749ac52":
> 	at org.hsqldb.lib.HsqlTimer$Task.getNextScheduled(HsqlTimer.java:763)
> 	- waiting to lock <0x00000007959e9bb0> (a org.hsqldb.lib.HsqlTimer$Task)
> 	at org.hsqldb.lib.HsqlTimer.compare(HsqlTimer.java:108)
> 	at org.hsqldb.lib.HsqlArrayHeap.add(HsqlArrayHeap.java:122)
> 	- locked <0x00000005e9008720> (a org.hsqldb.lib.HsqlTimer$TaskQueue)
> 	at org.hsqldb.lib.HsqlTimer$TaskQueue.addTask(HsqlTimer.java:841)
> 	at org.hsqldb.lib.HsqlTimer.nextTask(HsqlTimer.java:558)
> 	at org.hsqldb.lib.HsqlTimer$TaskRunner.run(HsqlTimer.java:610)
> 	at java.lang.Thread.run(Thread.java:745)

At least at first sight, this smells more like a bug in HSQLDB itself 
than like a problem caused by invalid use of HSQLDB from LO code. 
According to Wikipedia, the current stable release of HSQLDB is 2.3.3 
(from June 2015), while LO's external/hsqldb appears to be 1.8.0 (at 
least, the tarball we use is named 
17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip).

And LO's configure.ac checks that the version is indeed 1.8,

   AC_MSG_ERROR([no, you need hsqldb >= 1.8.0.9 but < 1.8.1])

so looks like we're stuck with that, for whatever reason?  Anybody knows?