diff options
| author | Jan-Marek Glogowski <glogow@fbihome.de> | 2018-03-05 20:43:53 +0100 |
|---|---|---|
| committer | Michael Stahl <mstahl@redhat.com> | 2018-03-07 15:47:57 +0100 |
| commit | 0898760c20c44e18278c5cb7513d11d041820d42 (patch) | |
| tree | 84163171a5c451c6210181b487b42336fee57846 | |
| parent | 4775511f57693ac0ff10a29f6706db52d133da91 (diff) | |
tdf#116147 guard triggerRequestThreadAware
It didn't help putting a SolarMutexGuard into
VCLXButton::ProcessWindowEvent, which was my first suspect in my
own backtrace, as VCLXWindowImpl::OnProcessCallbacks releases it
to process the callbacks.
Since the gtk backend also guards all calls into the file picker
code, I think it's save to do the same for the Windows picker.
I have no idea where it is actually released again...
Change-Id: I3ab3b47904dc3d0033739a82f7afd91e6e80403d
Reviewed-on: https://gerrit.libreoffice.org/50783
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 3e38b81a65ced47595e9760bdc622d9434b72cc0)
Reviewed-on: https://gerrit.libreoffice.org/50796
Reviewed-by: Michael Stahl <mstahl@redhat.com>
| -rw-r--r-- | fpicker/source/win32/filepicker/asyncrequests.cxx | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/fpicker/source/win32/filepicker/asyncrequests.cxx b/fpicker/source/win32/filepicker/asyncrequests.cxx index e3e97a0e090b..766a2309d991 100644 --- a/fpicker/source/win32/filepicker/asyncrequests.cxx +++ b/fpicker/source/win32/filepicker/asyncrequests.cxx @@ -138,6 +138,7 @@ void AsyncRequests::triggerRequestThreadAware(const RequestRef& rRequest, { oslThreadIdentifier nOurThreadId = getIdentifier(); oslThreadIdentifier nCallerThreadId = ::osl::Thread::getCurrentIdentifier(); + SolarMutexGuard aGuard; if (nOurThreadId == nCallerThreadId) triggerRequestDirectly(rRequest); else if (nWait == BLOCKED) |