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?
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
