Created attachment 135732 [details]
output from bibisect in daily Linux dbgutil repository
(1) Open attachment to tdf#109353, Inventar_Physik.odb.
(2) Open form Gegenstand
(3) Drop down the drop-down list Raum
(4) Click second entry, "B 005". Program fails with terminal output
Assertion `ImplGetSVData()->mpDefInst->CheckYieldMutex() &&
"SolarMutex not locked"
Fatal exception: Signal 6
Working on debian-stretch in the daily Linux dbgutil bibisect
repository, I find that the bug started somewhere in the 55 commits to
commit date s-h
-------- ---------- --------
good 478c063d 2017-06-12 6a241608
bad 00bcd29f 2017-06-13 a1ace08b
In this range, this commit message mentions Mutex:
Author: Arnaud Versini <email@example.com>
Date: Mon Jun 5 16:12:27 2017 +0200
Remove VCLExternalSolarLock and IMutex.
Next step is to remove OContextEntryGuard.
Tested-by: Jenkins <firstname.lastname@example.org>
Reviewed-by: Noel Grandin <email@example.com>
Created attachment 135733 [details]
typescript of make debugrun
252 info threads
273 thread apply all backtrace
512 backtrace full
This is from a local-build LibreOffice, commit 461ba1db, 2017-08-04
22:57 UTC, configured:
built and running on debian-stretch.
I observed, perhaps coincidentally, that the "good" versions I tested
while bibisecting each did not show values in the drop-down boxes or
in the opened drop-down lists. The "bad" versions did show values.
Whoops. The tale is more complicated: I managed to raise the same
assertion in drop-down list Regal in earlier version dbgutil
In the -till53 dbgutil repository, I narrowed the appearance of the
assertion on drop-down list Regal to the 64 source commits
42062d99..0d2797fd. In that range, I see
Author: Michael Meeks <firstname.lastname@example.org>
Date: Tue Oct 18 21:38:34 2016 +0100
vcl: assert solar mutex is held for various timer / scheduler ops.
Bringing paranoia to some source-code near you.
although, funnily enough, dbggui.cxx:47 is git blame'd to 2014.
I conclude that the problem is somewhere else, and that my good/bad
determinations while trying to bibisect are mere noise. I am removing
keywords bibisected, regression.
i think this assertion doesn't happen any more on master as the Scheduler no longer uses SolarMutex.
but the locking in that FmXFormShell class is still a disaster so i've hit it with the big hammer.
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":
tdf#111970 svx: use SolarMutex for locking in FmXFormShell
It will be available in 6.0.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:
Affected users are encouraged to test the fix and report feedback.
Indeed the problem is gone on debian-stretch in some recent versions
from the daily Linux dbgutil bibisect repository. I am setting status