diff options
| author | Jan-Marek Glogowski <glogow@fbihome.de> | 2018-03-05 20:43:53 +0100 |
|---|---|---|
| committer | Jan-Marek Glogowski <glogow@fbihome.de> | 2018-03-06 09:30:12 +0100 |
| commit | 3e38b81a65ced47595e9760bdc622d9434b72cc0 (patch) | |
| tree | 3533f64b601f27cfc9437c58c1f51e3886f5afe9 | |
| parent | 49cf733effc56c09c5e2eb023120c2d3532b5b3d (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>
| -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) |