Description: A basic macro which has worked for the last 10 years now hangs indefinitely. Event listeners are registered using com.sun.star.awt.Toolkit addDropTargetListener. Subroutines are in place to handle all the com.sun.star.datatransfer.dnd events. Previously if something was dragged onto the form, the listener would trigger, and the code would check to see if dropping was allowed (using a global variable which in my code is called boolFileStorage). If so, the filename was obtained and passed through to another routine. Now, since version 7.3.4.2 (via Fedora 36), upon a dragover, Libreoffice is immediately unresponsive. The basic IDE inbuilt debugger is no use as that freezes also. For that reason I am unable to work out which listener (if any) is hanging. My use case is within LibreOffice BASE, but I have copied and pasted the Macro into a Writer document which displays the same buggy behaviour. Steps to Reproduce: 1.Open sample document (attached) 2.Press the push button (to register the event handlers) 3.Drag a file onto the document Actual Results: Libreoffice hangs and all windows unresponsible without a kill -9 or "Force Quit" Expected Results: Drag icon should change to show that dropping is allowed; if the file is dropped on to the window, in the test code it should show the filename and a message box (in my production code it calls other routines). Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.4.2 Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.17; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 180837 [details] test document with macro
Created attachment 180884 [details] Backtrace Further to the above, I have added a backtrace. I am nowhere near enough knowlegdable about the workings of the LibO engine, but the point of hanging seems to be when it acquires a mutex lock at vcl/source/window/dndeventdispatcher.cxx:156. Only problem is that this code has been in place for some months now, so it doesn't explain the sudden crash, but perhaps something else has also obtained a mutex on another thread or in the background? Hope this helps!
Mike, Andreas, could you please look at it?
Created attachment 180941 [details] infostring result Tested with Version: 7.4.0.0.beta1+ / LibreOffice Community Build ID: 6ab56a4fc946f6294513f23a3ea47aa0aa154b7d CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo and if I correctly understand description, it works. See printscreen.
It oscillates between these two functions: https://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx?r=5bb5763e#5903 and https://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx?r=5bb5763e#5502 at least in: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4369640b86d2d15cb0c05706d92b29804de716f7 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
(In reply to Andreas Heinisch from comment #5) The code in the macro is non-portable (just as our own transferable flavor types), so it works differently (does not work) on Windows. And in any case, the internals (call stacks, locking, etc.) of DnD would be *completely* different on Windows compared to (different integrations for) Linux (the bug is against gtk3). Having said that: I wasn't able to repro the hang/crash on Ubuntu, using 7.3.4.2 (non-debug), and current master (dbgutil). There may be some additional specifics involved (like different kernel versions or other system differences), or it may be a heizenbug, dependent on e.g. timing, and thus ~reliably reproducible with debug builds on come CPU, but not with release build on another CPU (or something like that - you get the idea). Hope that there appear reliable repro steps allowing to repro on any Linux gtk3 system.
(In reply to Mike Kaganski from comment #6) Hi Mike, Is there anything further you'd like me to do? This is pretty critical to the system I use it for, so I've just gone back to LibO 7.2. If this turns out to be a "won't print on Tuesdays" type bug, then any tips on how to diagnose further? Thank you!
Caolan: maybe you can repro or suggest what info is missing? Thanks.
I can reproduce. Looks to me that https://gerrit.libreoffice.org/c/core/+/136401 solves it and its a problem since: commit 8de81db4e3fca488d50db2d74734109b31541a6f Date: Mon Aug 2 09:21:17 2021 +0200 osl::Mutex->std::mutex in DNDEventDispatcher
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/328b7a34255ed1ffb0029fa1f247d16ba92f18cd tdf#149626 use recursive_mutex to fix hang in macro callback during dnd It will be available in 7.5.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/9647f34412814ff9b14cd28a5c84a66d5f791ea5 tdf#149626 use recursive_mutex to fix hang in macro callback during dnd It will be available in 7.4.0.0.beta2. 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.
seems to work, backport to 7-3 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/04c481f7b276087699c6aa4f923e427298ac9cfa tdf#149626 use recursive_mutex to fix hang in macro callback during dnd It will be available in 7.3.5. 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.
Thanks all! Can confirm works on my system too. Kind regards, Dominic.