https://bugs.documentfoundation.org/show_bug.cgi?id=165202
Patrick (volunteer) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] --- Comment #5 from Patrick (volunteer) <[email protected]> --- (In reply to Alex Thurgood from comment #3) > Hmm, trawling through bugzilla hints that bug 148435 has resurfaced. Your Activity Monitor sample looks similar to the last sample in tdf#148435. Both samples have the grammar checker and other non-main threads waiting for something to unblock them. But the big difference is that on the main thread, this bug is in the accessibility code whereas tdf#148435 was the "idle task scheduler" code. So adding @Michael Weghorn to see if he has any insights into the locking code in accessibility::AccessibleBrowseBoxAccess::getAccessibleContext(). My memory is hazy, but I remember that tdf#148435 was caused by trying to lock a non-recursive mutex when it is already locked. In other words, tdf#148435 was due to using a non-recursive lock as a recursive lock. On macOS, trying to lock a non-recursive lock that is already lock results in a hang so possibly we need to replace the lock with a recursive lock? I can't tell from your sample if the mutex that accessibility::AccessibleBrowseBoxAccess::getAccessibleContext() is trying to lock is a non-recursive lock our not as, surprisingly, I couldn't find the code with a "grep -r AccessibleBrowseBoxAccess". :/ -- You are receiving this mail because: You are the assignee for the bug.
