Created attachment 174621 [details]
Internal FB DB hangs on opening
Opening the attached DB hangs on opening on Windows in Version: 126.96.36.199 (x64) / LibreOffice Community
Build ID: 3cfc32d9754d2d239bd8ce2941029c12873010c1
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
and also in current master.
I thought that the problem was incorrect check introduced in , but as hvlad clarified in , I misunderstood the problem.
Filing it here, and attach the problematic file to allow inspection, but still assume upstream bug.
*** Bug 144198 has been marked as a duplicate of this bug. ***
This is not related to the bug in the incorrect check - rather it's similar to https://github.com/FirebirdSQL/firebird/issues/4376. The problem is that FB uses a global locking mechanism with a name that is shared across all FB instances running on a session; and using a separate trace storage (which for LO is placed in LO's own temp directory) is unsupported by FB currently.
The problem is reproducible in one of the following ways:
1. Open FireBird's isql utility and connect to a local FDB; then open an ODB with embedded FB in LibreOffice, and try to open its tables;
2. Open a LibreOffice instance with an embedded FB ODB, and open a table in it; open another instance of LibreOffice (e.g., a dev build; or use another user profile) with another embedded FB ODB, and try to open its tables.
(the latter was how it occurred to me - the other running LO process was hung and invisible, and I needed to kill it).
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":
tdf#144172: patch FB to use per-process LOCK directories
It will be available in 7.3.0.
The patch should be included in the daily builds available at
https://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.