Description: Deadlocks when typing text in a table (Libreoffice writer) Steps to Reproduce: 1. typing text 2. 3. Actual Results: LibreOffice hangs Expected Results: no deadlocks Reproducible: Sometimes User Profile Reset: No Additional Info: Sampling process 9538 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling soffice (pid 9538) every 1 millisecond Process: soffice [9538] Path: /Applications/LibreOffice 2.app/Contents/MacOS/soffice Load Address: 0x100e5c000 Identifier: org.libreoffice.script Version: 7.2.6.2 (7.2.6.2) Code Type: X86-64 Parent Process: ??? [1] Date/Time: 2022-03-29 14:58:10.241 -0400 Launch Time: 2022-03-26 13:58:36.183 -0400 OS Version: Mac OS X 10.11.6 (15G22010) Report Version: 7 Analysis Tool: /usr/bin/sample ---- Call graph: 2735 Thread_302410 DispatchQueue_1: com.apple.main-thread (serial) + 2735 start (in libdyld.dylib) + 1 [0x7fff92bce5ad] + 2735 main (in soffice) + 16 [0x100e5cf60] + 2735 soffice_main (in libsofficeapp.dylib) + 248 [0x100f13a28] + 2735 ImplSVMain() (in libvcllo.dylib) + 109 [0x103e3c86d] + 2735 AquaSalInstance::SVMainHook(int*) (in libvclplug_osxlo.dylib) + 178 [0x1083092d2] + 2735 NSApplicationMain (in AppKit) + 1176 [0x7fff89aa9368] + 2735 -[NSApplication run] (in AppKit) + 796 [0x7fff89adfdf2] + 2735 -[VCL_NSApplication sendEvent:] (in libvclplug_osxlo.dylib) + 77 [0x10833d97d] + 2735 AquaSalInstance::handleAppDefinedEvent(NSEvent*) (in libvclplug_osxlo.dylib) + 91 [0x1083072cb] + 2735 ImplSVMain() (in libvcllo.dylib) + 139 [0x103e3c88b] + 2735 desktop::Desktop::Main() (in libsofficeapp.dylib) + 3691 [0x100ee663b] + 2735 Application::Execute() (in libvcllo.dylib) + 334 [0x103e3532e] + 2735 AquaSalInstance::DoYield(bool, bool) (in libvclplug_osxlo.dylib) + 799 [0x108307aaf] + 2735 AquaSalTimer::callTimerCallback() (in libvclplug_osxlo.dylib) + 71 [0x108316197] + 2735 Scheduler::CallbackTaskScheduling() (in libvcllo.dylib) + 738 [0x103e25522] + 2735 AquaSalInstance::AnyInput(VclInputFlags) (in libvclplug_osxlo.dylib) + 193 [0x108307db1] + 2735 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 454 [0x7fff89aeb226] + 2735 _DPSNextEvent (in AppKit) + 1067 [0x7fff89aebdf6] + 2735 _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox) + 71 [0x7fff8236d5af] + 2735 ReceiveNextEventCommon (in HIToolbox) + 184 [0x7fff8236d677] + 2735 RunCurrentEventLoopInMode (in HIToolbox) + 235 [0x7fff8236d935] + 2735 CFRunLoopRunSpecific (in CoreFoundation) + 296 [0x7fff93d80e28] + 2735 __CFRunLoopRun (in CoreFoundation) + 1949 [0x7fff93d8182d] + 2735 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ (in CoreFoundation) + 9 [0x7fff93dc2949] + 2735 _dispatch_main_queue_callback_4CF (in libdispatch.dylib) + 1685 [0x7fff8d95ec1c] + 2735 _dispatch_client_callout (in libdispatch.dylib) + 8 [0x7fff8d94b40b] + 2735 _dispatch_call_block_and_release (in libdispatch.dylib) + 12 [0x7fff8d95693d] + 2735 ImplNSAppPostEvent(short, signed char, int) (in libvclplug_osxlo.dylib) + 255 [0x108315d9f] + 2735 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 454 [0x7fff89aeb226] + 2735 _DPSNextEvent (in AppKit) + 1906 [0x7fff89aec13d] + 2735 _NSHandleCarbonMenuEvent (in AppKit) + 86 [0x7fff89c7703b] + 2735 _NSFindMenuItemMatchingCommandKeyEvent (in AppKit) + 300 [0x7fff89c8b99c] + 2735 +[NSCarbonMenuImpl _menuItemWithKeyEquivalentMatchingEventRef:inMenu:] (in AppKit) + 327 [0x7fff89c8bc12] + 2735 IsMenuKeyEvent (in HIToolbox) + 110 [0x7fff8238a1d4] + 2735 _IsMenuKeyEvent(MenuData*, OpaqueEventRef*, unsigned int, MenuData**, unsigned short*) (in HIToolbox) + 692 [0x7fff8238a4c0] + 2735 CheckMenusForKeyEvent(MenuData*, CheckMenuData*) (in HIToolbox) + 623 [0x7fff8238a7a7] + 2735 SearchCache(OpaqueCollection*, bool, bool, CheckMenuData*, MenuResult*) (in HIToolbox) + 556 [0x7fff8239e50f] + 2735 SearchCacheEntries(OpaqueCollection*, unsigned int, unsigned long, CheckMenuData*, MenuResult*, MenuData**, unsigned long*) (in HIToolbox) + 324 [0x7fff8239eac7] + 2735 PopulateMenu(MenuData*, OpaqueEventTargetRef*, CheckMenuData*, unsigned int, double) (in HIToolbox) + 90 [0x7fff8238bd74] + 2735 SendMenuPopulate(MenuData*, OpaqueEventTargetRef*, unsigned int, double, unsigned int, OpaqueEventRef*, unsigned char, unsigned char*) (in HIToolbox) + 320 [0x7fff8238bfcb] + 2735 SendEventToEventTargetWithOptions (in HIToolbox) + 43 [0x7fff82344aab] + 2735 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) (in HIToolbox) + 404 [0x7fff82344c48] + 2735 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) (in HIToolbox) + 1231 [0x7fff823457be] + 2735 NSSLMMenuEventHandler (in AppKit) + 708 [0x7fff89c8bfd9] + 2735 -[NSCarbonMenuImpl _carbonPopulateEvent:handlerCallRef:] (in AppKit) + 475 [0x7fff89c8c2ed] + 2735 -[NSMenu _populateWithEventRef:] (in AppKit) + 80 [0x7fff89c89725] + 2735 -[NSMenu _populateFromDelegateWithEventRef:] (in AppKit) + 336 [0x7fff89c8d190] + 2735 -[SalNSMenu menuNeedsUpdate:] (in libvclplug_osxlo.dylib) + 397 [0x10833ccbd] + 2735 ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) (in libvcllo.dylib) + 7267 [0x103b13bf3] + 2735 Menu::HandleMenuActivateEvent(Menu*) const (in libvcllo.dylib) + 142 [0x103aa5a3e] + 2735 Menu::Activate() (in libvcllo.dylib) + 145 [0x103a9d4d1] + 2735 framework::MenuBarManager::Activate(Menu*) (in libfwklo.dylib) + 1842 [0x10177b712] + 2735 SfxDispatchController_Impl::addStatusListener(com::sun::star::uno::Reference<com::sun::star::frame::XStatusListener> const&, com::sun::star::util::URL const&) (in libsfxlo.dylib) + 132 [0x101d0a9a4] + 2735 SfxDispatcher::QueryState(unsigned short, com::sun::star::uno::Any&) (in libsfxlo.dylib) + 198 [0x101cc1dd6] + 2735 SfxShell::GetSlotState(unsigned short, SfxInterface const*, SfxItemSet*) (in libsfxlo.dylib) + 593 [0x101cdc471] + 2735 Idle::Start() (in libvcllo.dylib) + 14 [0x103deb03e] + 2735 Task::Start() (in libvcllo.dylib) + 35 [0x103e25c73] + 2735 std::__1::mutex::lock() (in libc++.1.dylib) + 9 [0x7fff91124f6d] + 2735 _pthread_mutex_lock_wait (in libsystem_pthread.dylib) + 89 [0x7fff8e23ce4a] + 2735 __psynch_mutexwait (in libsystem_kernel.dylib) + 10 [0x7fff8561ede6] 2735 Thread_302818 DispatchQueue_2: com.apple.libdispatch-manager (serial) + 2735 _dispatch_mgr_thread (in libdispatch.dylib) + 52 [0x7fff8d950dcd] + 2735 _dispatch_mgr_invoke (in libdispatch.dylib) + 216 [0x7fff8d951165] + 2735 kevent_qos (in libsystem_kernel.dylib) + 10 [0x7fff8561fefa] 2735 Thread_302846: PipeIPC + 2735 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff8e23a351] + 2735 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff8e23c91a] + 2735 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff8e23c99d] + 2735 osl_thread_start_Impl(void*) (in libuno_sal.dylib.3) + 122 [0x100e9bd0a] + 2735 threadFunc (in libuno_salhelpergcc3.dylib.3) + 15 [0x101a4b9bf] + 2735 salhelper::Thread::run() (in libuno_salhelpergcc3.dylib.3) + 27 [0x101a4b84b] + 2735 desktop::PipeIpcThread::execute() (in libsofficeapp.dylib) + 65 [0x100f105a1] + 2735 osl_acceptPipe (in libuno_sal.dylib.3) + 25 [0x100e94a39] + 2735 __accept (in libsystem_kernel.dylib) + 10 [0x7fff8561e3ca] 2735 Thread_302848: com.apple.NSEventThread + 2735 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff8e23a351] + 2735 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff8e23c91a] + 2735 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff8e23c99d] + 2735 _NSEventThread (in AppKit) + 149 [0x7fff89c41d95] + 2735 CFRunLoopRunSpecific (in CoreFoundation) + 296 [0x7fff93d80e28] + 2735 __CFRunLoopRun (in CoreFoundation) + 1356 [0x7fff93d815dc] + 2735 __CFRunLoopServiceMachPort (in CoreFoundation) + 212 [0x7fff93d82114] + 2735 mach_msg (in libsystem_kernel.dylib) + 55 [0x7fff856183b3] + 2735 mach_msg_trap (in libsystem_kernel.dylib) + 10 [0x7fff85618f72] 2735 Thread_304138: GrammarCheckingIterator 2735 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff8e23a351] 2735 _pthread_start (in libsystem_pthread.dylib) + 168 [0x7fff8e23c91a] 2735 _pthread_body (in libsystem_pthread.dylib) + 131 [0x7fff8e23c99d] 2735 osl_thread_start_Impl(void*) (in libuno_sal.dylib.3) + 122 [0x100e9bd0a] 2735 GrammarCheckingIterator::DequeueAndCheck() (in liblnglo.dylib) + 1803 [0x10798216b] 2735 GrammarCheckingIterator::ProcessResult(com::sun::star::linguistic2::ProofreadingResult const&, com::sun::star::uno::Reference<com::sun::star::text::XFlatParagraphIterator> const&, bool) (in liblnglo.dylib) + 1203 [0x107980b13] 2735 SwXTextMarkup::commitMultiTextMarkup(com::sun::star::uno::Sequence<com::sun::star::text::TextMarkupDescriptor> const&) (in libswlo.dylib) + 59 [0x16de582cb] 2735 SalYieldMutex::doAcquire(unsigned int) (in libvclplug_osxlo.dylib) + 384 [0x108306880] 2735 osl_acquireMutex (in libuno_sal.dylib.3) + 14 [0x100e93c6e] 2735 _pthread_mutex_lock_slow (in libsystem_pthread.dylib) + 300 [0x7fff8e23a5f5] 2735 _pthread_mutex_lock_wait (in libsystem_pthread.dylib) + 89 [0x7fff8e23ce4a] 2735 __psynch_mutexwait (in libsystem_kernel.dylib) + 10 [0x7fff8561ede6] Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): __psynch_mutexwait (in libsystem_kernel.dylib) 5470 __accept (in libsystem_kernel.dylib) 2735 kevent_qos (in libsystem_kernel.dylib) 2735 mach_msg_trap (in libsystem_kernel.dylib) 2735
Created attachment 179194 [details] Sample Process (LibreOffice - Deadlock) Typing in a table cell. First 4 characters were "oper" entered ok. Deadlocked on or before the fifth character "a".
No repro in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 51fb84829afbc1c0957fd1a489085613ad199f1a CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL Jumbo macOS only?
no repro in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 0a05b1f46263a16c6d40c841a317c3ba9f4d31d6 CPU threads: 4; OS: Mac OS X 12.3.1; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded possible the problem is in your old macOS version -> OS Version: Mac OS X 10.11.6 Will you plan to update it?
@Frank : If you turn off and/or remove whichever spell/grammar checking tool you are using (whether default langpack provided or 3rd party), does it work OK ?
Created attachment 179308 [details] Thread stack - Deadlock with all Writing Aids turned off Here is the updated Thread stack after deadlock occurs with all Writing Aids turned off
After turning all writing aids off (Except "List of Ignored Words" under User-define Dictionaries - UI will not allow me to deselect this option) Writer still results in deadlock when editing a table cell. I have uploaded the newly generated thread stack.
[Automated Action] NeedInfo-To-Unconfirmed
@Frank : just out of interest, might I ask which toolbar layout you are using ? I also see from the most recent trace sampling that the mutex wait gets called after activation of a toolbar layout, and then idling : 2739 Menu::HandleMenuActivateEvent(Menu*) const (in libvcllo.dylib) + 142 [0x10b43ea3e] + 2739 Menu::Activate() (in libvcllo.dylib) + 145 [0x10b4364d1] + 2739 framework::MenuBarManager::Activate(Menu*) (in libfwklo.dylib) + 1842 [0x10912a712] + 2739 SfxDispatchController_Impl::addStatusListener(com::sun::star::uno::Reference<com::sun::star::frame::XStatusListener> const&, com::sun::star::util::URL const&) (in libsfxlo.dylib) + 132 [0x1096ae9a4] + 2739 SfxDispatcher::QueryState(unsigned short, com::sun::star::uno::Any&) (in libsfxlo.dylib) + 198 [0x109665dd6] + 2739 SfxShell::GetSlotState(unsigned short, SfxInterface const*, SfxItemSet*) (in libsfxlo.dylib) + 593 [0x109680471] + 2739 Idle::Start() (in libvcllo.dylib) + 14 [0x10b78403e] From this, it does seem like a scheduling issue, but perhaps it is only triggered in certain circumstances.
In response to toolbar layout used question I have included how my view menu looks like View\Normal: Checked View\User Interface: Standard Toolbar View\Toolbars: (Drawing, Formatting, Standard, Table, Lock Toolbars) View\Status Bar: Checked View\Text Boundaries: Checked View\Table Boundaries: Checked View\Image and Charts: Checked View\Show Tracked Changes: Checked View\Sidebar: Checked View\Gallery: Checked @Alex Hopefully this answers your question. If not let me know where I can find the information you are looking for.
@Roman The machine does not support a newer version of MacOS. However, I was able to run the same test on a 2nd machine with MacOS 10.14.6. So far I have not been able to reproduce the deadlock on the 2nd machine. I also tried limiting the cores via XCode instruments to increase the chance of instruction order related deadlocking issues but have not been able to reproduce the issue. The deadlock issue may be specific to the MacOS version. I will run an older version of LibreOffice on the problematic machine. Thanks to everyone that reviewed this issue.
I'd be inclined to mark this as a DUP of bug 148435
@Frank: Are you using any window manager software on your mac?
@Steve No I am not using any window manager. However, I do have some more information on this issue. Deadlocks would occur for various activities, however under certain test environments (see end of post) certain actions would trigger the deadlock with high probability. Environment A would show this for typing text in a table consistently. However, I think that typing text into a table is just a red herring for the deadlock issue. I think it maybe related to toolbar state. Process ~~~~~~~~ What I did try to do was to make LibreOffice the same for all 3 testing environments since there was some discussion that it may be an OS version issue. This included completely clearing out "~/Library/Application Support/libreoffice/4/" files and reinstalling from the same install image. Dead Lock Observations ~~~~~~~~~~~~~~~~~~~~~~ Running with a clean install and default setup in general reduced the frequency of deadlocks. However after copying my desired setting files back the frequency of deadlocks increase. Staring from the default setup and making changes manually it seems like increasing the number of visible toolbars and increasing the number of tools on the tool bar increased deadlock. So it is not likely a corrupt settings file. When selecting "User Interface \ Single Tool bar" it was much more difficult to reproduce deadlock in all 3 environments. With lots a tool bars showing just losing focus could trigger a dead-lock (spinning ball would briefly appear before libreoffice lost focus then when clicking on libreoffice again it would be in deadlock). I could get this to occur in environments A and B pretty consistently. It would happen in environment C intermittently and often took a lot of work / time to trigger. I also noticed that toolbar state would change (grey-out tools) when losing focus to another application. Unstable Versions ~~~~~~~~~~~~~~~~~ Both libreoffice version 7.2.6 and version 7.2.7 suffers from deadlock. In environments A and B I would get a deadlocks with my preferred toolbar settings consistently for certain actions (get deadlock, restart, perform same action and get deadlock again) and randomly maybe every hour of usage. In environment C I would get deadlock maybe once a day sometimes less when using it all day. Stable Version ~~~~~~~~~~~~~~~~~ I have now been using version 6.2.8.2 daily on large documents for over 3 months without a single dead-lock. It seams like version 6.2.8.2 does not suffer from this issue. Testing Environments (A, B, C) ~~~~~~~~~~~~~~~~~~~ A) On MacOS (10.11.6) running very old hardware dead locks were easily reproducible when editing table text. B) On MacOS (10.14.6) running on old hardware dead locks occurred but sporadically. C) On MacOS (12.6) running on newer hardware dead locks occurred but where harder to reproduce (hours). Not sure if the differences in dead lock reproducibility is due to the OS version or hardware or a combination of the two. I'm guessing it is a timing thing which would be affected by both hardware and software.
*** This bug has been marked as a duplicate of bug 148435 ***