Description: 1) Downloaded the latest available jdbcDriverOOo extension from the github repo. 2) Tried to install it by dragging and dropping onto a runnning instance of Version: 7.6.4.1 (AARCH64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Mac OS X 14.2.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded 3) The extension manager GUI is started and user asked to confirm installation of the extension, but then it hangs, requiring a force kill to shut LO down. 4) On restart, the extension appears in the list of installed extensions, but there is no corresponding entry in the DB creation wizard, i.e. trying to connecto to an existing database per the documentation doesn't show a HSQLDB entry in the list of possible database types. There doesn't appear to be any classpath entries either under the Advanced settings dialog in the Java setup. Steps to Reproduce: See description above. Actual Results: Attempting to install the extension causes a LO process hang, requiring forced kill to quit. The extension does not install, and does not make the described functionality available, even though the extensions manager GUI indicates that the extension has been installed. Expected Results: The extension should install without causing the hang, and be functional after successful installation. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.6.4.1 (AARCH64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Mac OS X 14.2.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Created attachment 192656 [details] Spindump produced by Apple process monitoring utility on hang
Hi, I have never used it on a Mac Arm, however I had already tested it on a Raspberry Pi4B microcomputer which is Arm architecture and it worked well. Unfortunately these tests are already more than a year old and therefore I am not sure that this is true for the latest versions. Stupid question, but you have Java version 11 minimum?
Yes I prefer to insist, but you also have to install the Python packages with a pip install of the requirements.txt[1] file [1] https://github.com/prrvchr/jdbcDriverOOo/releases/download/v1.2.0/requirements.txt
(In reply to prrvchr from comment #3) > Yes I prefer to insist, but you also have to install the Python packages > with a pip install of the requirements.txt[1] file > > [1] > https://github.com/prrvchr/jdbcDriverOOo/releases/download/v1.2.0/ > requirements.txt Homebrew output: six 1.16.0_4 is already installed and up-to-date python-setuptools 69.1.1 is already installed and up-to-date python-packaging 23.2_1 is already installed and up-to-date.
(In reply to prrvchr from comment #2) > Stupid question, but you have Java version 11 minimum? openjdk 21.0.2 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode)
I think I have a fix for this bug in the following patch: https://gerrit.libreoffice.org/c/core/+/165682 The sample in attachment #192656 [details] shows a deadlock between two threads due to each thread locking the same two locks but in reverse order.
(In reply to Patrick Luby (volunteer) from comment #6) > I think I have a fix for this bug in the following patch: > > https://gerrit.libreoffice.org/c/core/+/165682 > > The sample in attachment #192656 [details] shows a deadlock between two > threads due to each thread locking the same two locks but in reverse order. I forgot to add that I only tested that the jdbcDriverOOo extension installs, LibreOffice restarts, extension uninstalls, and LibreOffice restarts without hanging. Note: with my fix in my local build, it takes roughly a minute for the jdbcDriverOOo extension installation to complete.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/89e23bb599104d3bde30878148e15cf4deb1593f tdf#159790 eliminate deadlock on main thread It will be available in 24.8.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Patrick, It's really great if it's possible to install on ARM. > it takes roughly a minute for the jdbcDriverOOo extension installation to complete. Under Ubuntu it takes me less than 10 seconds and under Windows 10 under VirtualBox it takes 40 seconds...
(In reply to prrvchr from comment #9) > It's really great if it's possible to install on ARM. > > Under Ubuntu it takes me less than 10 seconds and under Windows 10 under > VirtualBox it takes 40 seconds... It's down to around 20 seconds or so on my 2021 Silicon Mac, MacBook Pro after some improvements to my fix by another LibreOffice engineer. I am running locally-built debug builds so a lot of the optimizations in the LibreOffice code are disable. Maybe it will be faster in the nightly master builds. Anyway, the fix for this bug has been committed. The fix should be in tomorrow's (03 April 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/677b13aa5c695b44ada7a0b11d6c9b91fc38ff51 tdf#159790 eliminate deadlock on main thread It will be available in 7.6.7. 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/27279b82c4e98271db9e999200c70ee8cba11c38 tdf#159790 eliminate deadlock on main thread It will be available in 24.2.3. 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Patrick Luby (volunteer) from comment #10) > It's down to around 20 seconds or so on my 2021 Silicon Mac, MacBook Pro > after some improvements to my fix by another LibreOffice engineer. I am > running locally-built debug builds so a lot of the optimizations in the > LibreOffice code are disable. Maybe it will be faster in the nightly master > builds. It's much faster in today's nightly master build. It takes less than 5 seconds to install after accepting the license on my Silicon MacBook Pro.
Faster than Linux, very good job...
Hmm, still freezing for me with 24.8.0.0 (24.8.0.0.alpha0) Is First Party: No Beta Identifier: D3694220-50B6-55A9-A2E2-508C8042D7C6 Architecture: arm64 PID: 13439 downloaded from LibreOffice master daily 03/04/2024 Attaching Apple Trace after forced kill.
Created attachment 193465 [details] Apple Trace after forced kill on hang
(In reply to Alex Thurgood from comment #16) > Created attachment 193465 [details] > Apple Trace after forced kill on hang Your sample looks like it doesn't have Noel's fix. The main thread is still blocking trying to acquire the lock in dp_registry::backend::Package::isRegistered(com::sun::star::uno::Reference<com::sun::star::task::XAbortChannel> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) whereas the non-main thread is in the code that Noel's fix released the lock. @Noel Are we sure that your fix releases the same lock that the main thread is trying to acquire? Or should we revert back to my original fix?
(In reply to Patrick Luby (volunteer) from comment #17) > @Noel Are we sure that your fix releases the same lock that the main thread > is trying to acquire? Or should we revert back to my original fix? Did some debugging and it is looks like the main thread calls Package::isRegistered() on *all* extensions repeatedly but Noel's fix only temporarily releases the lock on only on the extension currently being installed. So, I suspect that the main thread is calling Package::isRegistered() on a different package instance than the one that is currently being installed. Maybe I am missing something, but it seems to me that the other package instances that aren't being installed have locked each of their respective locks even though no code is working on them.
(In reply to Patrick Luby (volunteer) from comment #18) > So, I suspect that the main thread is calling Package::isRegistered() on a > different package instance than the one that is currently being installed. > Maybe I am missing something, but it seems to me that the other package > instances that aren't being installed have locked each of their respective > locks even though no code is working on them. Found the problem. The fix temporarily released the current package's lock but not its parent package's lock. I cannot reproduce this bug but I have submitted the following patch that I hope fixes the hang in attachment #193465 [details]: https://gerrit.libreoffice.org/c/core/+/165766
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cab028121bd9b620529b6492b3247ac48ac2082b tdf#159790 temporarily release mutex for child packages It will be available in 24.8.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So the second fix should be in tomorrow's (05 April 2024) nightly master build. If the hang when installing the extension stops occurring, can you also try uninstalling the extension as well? From my debugging, it doesn't appear that the main thread is constantly querying the state of the extensions so hopefully we don't see a hang there. But, if there is, I can try applying the same "unlock parent package's lock" to uninstallation as well.
(In reply to Patrick Luby (volunteer) from comment #21) > So the second fix should be in tomorrow's (05 April 2024) nightly master > build. > > If the hang when installing the extension stops occurring, can you also try > uninstalling the extension as well? From my debugging, it doesn't appear > that the main thread is constantly querying the state of the extensions so > hopefully we don't see a hang there. But, if there is, I can try applying > the same "unlock parent package's lock" to uninstallation as well. @Patrick, I've said this before, and I'll say it again - you are a star ! The extension now installs in about 5 seconds after agreeing to the T&Cs. Similarly, uninstallation is also as quick. Thank you ! Alex
Glad to hear that the deadlock is now fixed. But Noel deserves most of the credit for this fix. My original fix was just a guess but Noel had a better, less risky approach.
Well I can easily add my thanks to Noel, without whom, many bugs would have been left unresolved! He has also been more than kind and generous in the past to me when I was attempting to build LO on macOS, coming to my aid on multiple occasions.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/96a40862fa010d9022247524913ac51e1d8b189a tdf#159790 temporarily release mutex for child packages It will be available in 24.2.3. 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/47ca58be2941e67c9304cf47d4beba93bdf74ffc tdf#159790 temporarily release mutex for child packages It will be available in 7.6.7. 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.