Testing the WordCount beanshell macro on OSX with master build causes LO to deadlock / freeze / hang (beachball mode) requiring forced kill.
How to reproduce : 1) Open Writer document, type some text. 2) Select the text with mouse. 3) Tools > Macros > Run Macro > Wordcount > wordcount.bsh > Run 4) Hang until force kill
JDK 1.8.0_102
Version: 5.3.0.0.alpha0+ Build ID: 3e7a6544da370f641b21fd03a86a1c84d6ea6576 CPU Threads: 2; OS Version: Mac OS X 10.11.6; UI Render: default; Locale: fr-FR (fr.UTF-8); Calc: group
Tested against Version: 5.1.5.2 Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5 CPU Threads: 2; OS Version: Mac OS X 10.11.6; UI Render: default; Locale: fr-FR (fr.UTF-8); Calc: group Reproducible also with this version.
Attempting the same procedure in LO 5032 causes a crash on execution of the macro, leading to a hung document recovery window requiring forced kill.
Attempting to reproduce with Version: 5.0.0.4 Build ID: cf112dc905650fb985306a7a03d2fe3fcc6c978f Locale: fr-FR (fr.UTF-8) OSX 10.11.4 leads to complete crash after selecting the wordcount.bsh entry in Run Macro dialog and clicking on Run.
So, from what I can attempt to understand in the enclosed backtrace, there seems to be some incomaptibility in the JNF code that the script has to use which causes the JVM to sigsegv multiple times, and this nonetheless attempts to instantiate the macro dialog warn:vcl:80504:1:vcl/source/window/dialog.cxx:788: Dialog::StartExecuteModal() - Parent not visible
Created attachment 126665 [details] backtrace from lldb debugging session
@Stephan : one for you ?
With my local master build and JDK 1.8.0_77, causes a crash as follows (and then goes beachball): > * thread #1: tid = 0x20d09, 0x000000012aef9472 libjvm.dylib`ThreadStateTransition::trans_from_native(JavaThreadState) + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV > frame #0: 0x000000012aef9472 libjvm.dylib`ThreadStateTransition::trans_from_native(JavaThreadState) + 10 > libjvm.dylib`ThreadStateTransition::trans_from_native: > -> 0x12aef9472 <+10>: movl $0x5, 0x270(%rbx) > 0x12aef947c <+20>: leaq 0x77afb5(%rip), %rax ; os::_processor_count > 0x12aef9483 <+27>: movl (%rax), %eax > 0x12aef9485 <+29>: cmpl $0x1, %eax > (lldb) bt > * thread #1: tid = 0x20d09, 0x000000012aef9472 libjvm.dylib`ThreadStateTransition::trans_from_native(JavaThreadState) + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV > * frame #0: 0x000000012aef9472 libjvm.dylib`ThreadStateTransition::trans_from_native(JavaThreadState) + 10 > frame #1: 0x000000012b0a1ab2 libjvm.dylib`jni_IsSameObject + 48 > frame #2: 0x0000000146c681f5 JavaNativeFoundation`-[JNFWeakJObjectWrapper _getWithEnv:] + 37 > frame #3: 0x0000000146c6848f JavaNativeFoundation`-[JNFJObjectWrapper jObjectWithEnv:] + 29 > frame #4: 0x000000015189637c libawt_lwawt.dylib`-[AWTWindow _deliverMoveResizeEvent] + 164 > frame #5: 0x00007fff96523bbc CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 > frame #6: 0x00007fff96523b4f CoreFoundation`___CFXRegistrationPost_block_invoke + 63 > frame #7: 0x00007fff96523ac7 CoreFoundation`_CFXRegistrationPost + 407 > frame #8: 0x00007fff96523832 CoreFoundation`___CFXNotificationPost_block_invoke + 50 > frame #9: 0x00007fff964e05e2 CoreFoundation`-[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1922 > frame #10: 0x00007fff964df835 CoreFoundation`_CFXNotificationPost + 693 > frame #11: 0x00007fff91fe017a Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 66 > frame #12: 0x00007fff8fe7aa4a AppKit`-[NSWindow _setFrameCommon:display:stashSize:] + 3507 > frame #13: 0x00007fff8fe79c88 AppKit`-[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 222 > frame #14: 0x00007fff8fe79ba3 AppKit`-[NSWindow setFrame:display:] + 67 > frame #15: 0x0000000151898970 libawt_lwawt.dylib`__Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds_block_invoke_1 + 284 > frame #16: 0x0000000146c685f5 JavaNativeFoundation`+[JNFRunLoop _performCopiedBlock:] + 20 > frame #17: 0x00007fff9204ffde Foundation`__NSThreadPerformPerform + 279 > frame #18: 0x00007fff9652d881 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > frame #19: 0x00007fff9650cf37 CoreFoundation`__CFRunLoopDoSources0 + 423 > frame #20: 0x00007fff9650c4df CoreFoundation`__CFRunLoopRun + 927 > frame #21: 0x00007fff9650bed8 CoreFoundation`CFRunLoopRunSpecific + 296 > frame #22: 0x00007fff8a534935 HIToolbox`RunCurrentEventLoopInMode + 235 > frame #23: 0x00007fff8a534677 HIToolbox`ReceiveNextEventCommon + 184 > frame #24: 0x00007fff8a5345af HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71 > frame #25: 0x00007fff8fda8df6 AppKit`_DPSNextEvent + 1067 > frame #26: 0x00007fff8fda8226 AppKit`-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454 > frame #27: 0x0000000106a838f6 libvcllo.dylib`AquaSalInstance::DoYield(this=0x000000010ecdd680, bWait=false, bHandleAllCurrentEvents=false, nReleased=0) + 998 at /Users/stephan/Software/lo/core/vcl/osx/salinst.cxx:623 > frame #28: 0x000000010691dbec libvcllo.dylib`ImplYield(i_bWait=false, i_bAllEvents=false, nReleased=0) + 1788 at /Users/stephan/Software/lo/core/vcl/source/app/svapp.cxx:508 > frame #29: 0x000000010691d4a8 libvcllo.dylib`Application::Yield() + 24 at /Users/stephan/Software/lo/core/vcl/source/app/svapp.cxx:555 > frame #30: 0x000000010691d41e libvcllo.dylib`Application::Execute() + 478 at /Users/stephan/Software/lo/core/vcl/source/app/svapp.cxx:472 > frame #31: 0x0000000100128679 libsofficeapp.dylib`desktop::Desktop::DoExecute() + 9 at /Users/stephan/Software/lo/core/desktop/source/app/app.cxx:1319 > frame #32: 0x000000010012b817 libsofficeapp.dylib`desktop::Desktop::Main(this=0x00007fff5fbffad8) + 12695 at /Users/stephan/Software/lo/core/desktop/source/app/app.cxx:1646 > frame #33: 0x000000010692be3a libvcllo.dylib`ImplSVMain() + 186 at /Users/stephan/Software/lo/core/vcl/source/app/svmain.cxx:185 > frame #34: 0x0000000106a82d99 libvcllo.dylib`AquaSalInstance::handleAppDefinedEvent(pEvent=0x00000001147005f0) + 249 at /Users/stephan/Software/lo/core/vcl/osx/salinst.cxx:466 > frame #35: 0x0000000106bd2ac0 libvcllo.dylib`-[VCL_NSApplication sendEvent:](self=0x000000010ed09000, _cmd="sendEvent:", pEvent=0x00000001147005f0) + 80 at /Users/stephan/Software/lo/core/vcl/osx/vclnsapp.mm:82 > frame #36: 0x00007fff8fd9cdf2 AppKit`-[NSApplication run] + 796 > frame #37: 0x00007fff8fd66368 AppKit`NSApplicationMain + 1176 > frame #38: 0x0000000106a810da libvcllo.dylib`ImplSVMainHook(pnInit=0x00007fff5fbffa54) + 522 at /Users/stephan/Software/lo/core/vcl/osx/salinst.cxx:211 > frame #39: 0x000000010692d75c libvcllo.dylib`SVMain() + 44 at /Users/stephan/Software/lo/core/vcl/source/app/svmain.cxx:220 > frame #40: 0x000000010019e196 libsofficeapp.dylib`soffice_main + 534 at /Users/stephan/Software/lo/core/desktop/source/app/sofficemain.cxx:165 > frame #41: 0x0000000100000f5d soffice`sal_main + 13 at /Users/stephan/Software/lo/core/desktop/source/app/main.c:48 > frame #42: 0x0000000100000f37 soffice`main(argc=1, argv=0x00007fff5fbffbc0) + 39 at /Users/stephan/Software/lo/core/desktop/source/app/main.c:47 > frame #43: 0x00007fff8a4495ad libdyld.dylib`start + 1 > (lldb) reg read rbx > rbx = 0x0000000000000000
Hi Alex, Can you explain why it's a regression? it's because in 5.1.5.2 is hanging and in 5.0.0.4 is crashing?
I was convinced that this worked in earlier versions of LO, with an older version of OSX and JavaforOSX (Apple's own Java). However, as that is now defunct, and even when installed on OSX10.12 and recognized by LO (which is no longer systematic), all I get are error messages with the earlier versions of LO, but indeed, the earlier versions of LO don't crash. Java error messages (attempt to instantiate JVM from thread that is not main), but no crash/hang with : LO330 LO4162 LO4452 so the crash/hang is a regression over previous behaviour (which admittedly wasn't brilliant in and of itself).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Testing with Version: 6.1.1.2 Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b Threads CPU : 8; OS : Mac OS X 10.13.6; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded causes an immediate closure of the Writer window, and the soffice process hangs, see enclosed Apple stack trace. A force kill is required to release the hung instance.
Created attachment 145011 [details] Apple stacktrace after LO hangs
Testing in Version: 6.2.0.2 Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded displays an error message (in French) : An undetected error has been identified. Choose "Continue" to keep running the application in an unstable state. Choose "Force Quit" to stop the application and create a bug report via the Crash Reporter. If you choose "Force Quit", any unsaved data will be lost.
Irrespective of the choices on offer in that error message, the app is unresponsive and so no button clicks on the error dialog can be activated. Force kill via the system process manager is required.
@Jan Marek: saw you did some work recently on Beanshell instantiation and vcl lifecycle - perhaps this is similar to the problem you were adressing ?
(In reply to Alex Thurgood from comment #18) > @Jan Marek: saw you did some work recently on Beanshell instantiation and > vcl lifecycle - perhaps this is similar to the problem you were adressing ? Feel free to test, if this is fixed by current master, but that just restores a working Beanshell editor.
Still happening with Version: 6.4.0.0.alpha0+ Build ID: 75d35ef8df1936dd93d5919b688abcaddb58bee8 CPU threads: 4; OS: Mac OS X 10.14.5; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded 1) Start LO 2) Open a new Writer document 3) Tools > Macros > Run Macro 4) Select WordCount beanshell macro, click Run. 5) Crash, message displayed that LibreOffice crashed unexpectedly, no interaction with dialog possible, application is hung (beachball) and requires forced kill.
Still happening with LO7.1RC1 (7.1.0.1) cf attached Apple Stack Trace
Created attachment 169495 [details] Apple Stack Trace
Still reproducible in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: bc7baa18435000f47f90e47d3300710bcb4cf56b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Created attachment 186001 [details] Apple Crash Trace
This is still happening with Version: 7.5.1.2 (AARCH64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Reproducible also in Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 4ca4282517d02592966576fc642048b3d5ae5532 CPU threads: 8; OS: Mac OS X 13.3; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Still reproducible with Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Mac OS X 14.0; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Enclosing updated Apple Stack Trace.
Created attachment 190166 [details] Apple Stack Tarce 20231012
The app now just crashes completely, even the recovery dialog appears and then disappears, and the app is removed from the macOS Dock.
Little point in setting priority to major, despite it being an unfixed regression. In 7 years, this bug has garnered almost no interest. Lowering priority.
@Patrick, I thought you might be interested in this issue
(In reply to Xisco Faulí from comment #31) > @Patrick, I thought you might be interested in this issue Remember, this can't possibly work with MAS versions, as Java instantiation is deliberately deactivated and Beanshell requires a JNI call: 0 libjvm.dylib 0x4f9437bb8 JNIHandleBlock::allocate_handle(JavaThread*, oopDesc*, AllocFailStrategy::AllocFailEnum) + 60 1 libjvm.dylib 0x4f93f3774 jni_NewLocalRef + 312 Any search for a remedy would only be valid for the non-crippled version of LO available from the LibreOffice download website.
I can reproduce this in my local master build as well. AFAICT, the crash is happening within Java when BeanShell creates a Java Swing GUI component. Specifically, the crash is occurring in the "wordsLabel = new JLabel("Word count = " + numWords);" line in LibreOfficeDev.app/Contents/Resources/Scripts/beanshell/WordCount/wordcount.bsh. Not sure how to debug something like this.
I went way down a rabbit hole today and got OpenJDK to build. With a few softlinks in /Library/Java/JavaVirtualMachines, LibreOffice could see it and, with a debug build of OpenJDK, the crash logs started to be more specific as to which function the crash was occurring in. So, after chasing some wild theories, I've got a patch that works for me: https://gerrit.libreoffice.org/c/core/+/157985
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fc69d6b227310b170a9690e0b2658d36a8e2ca6c tdf#101376 don't detach thread if it is the main thread on macOS It will be available in 24.2.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.
My fix should be in tomorrow's (16 October 2023) nightly master build. If anyone can verify that my fix works for you, I will backport my fix back to LibreOffice 7.5 and 7.6.
(In reply to Patrick Luby from comment #36) > My fix should be in tomorrow's (16 October 2023) nightly master build. If > anyone can verify that my fix works for you, I will backport my fix back to > LibreOffice 7.5 and 7.6. I'll wait for it to be released and should be able to test. Thanks for looking at this, tracking down the problem and sorting it out!
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/a7340bbc89739ac1ef64ae605d71bf4053b3b3ac tdf#101376 don't detach thread if it is the main thread on macOS It will be available in 7.6.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-5": https://git.libreoffice.org/core/commit/a976edfa525d87c7174861bca5eecd4ee804132d tdf#101376 don't detach thread if it is the main thread on macOS It will be available in 7.5.9. 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-5-8": https://git.libreoffice.org/core/commit/58320647950df01f1a23d07a90425e0b466a7f9d tdf#101376 don't detach thread if it is the main thread on macOS It will be available in 7.5.8. 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.
Verified fixed in Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 9395171aa8641341316f87e2537dcdfa3df4ef78 CPU threads: 8; OS: Mac OS X 14.0; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Thanks Patrick, nice job !