[Libreoffice-bugs] [Bug 106282] Crash in: windows.storage.dll when hitting cancel in file open dialog, when a file search is running

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=106282

--- Comment #19 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to Julien Nabet from comment #18)
> It makes me think about this log I got when just launching an LO module
> (Writer/Calc/Impress/...) (Win10 with master sources updated today):
> warn:extensions.olebridge:17940:13228:extensions/source/ole/olethread.cxx:41:
> CoInitializeEx failed (expectedly): Impossible de modifier le mode thread
> une fois qu’il a été fixé. (= Impossible to change thread mode once it has
> been defined)
> warn:extensions.olebridge:17940:13228:extensions/source/ole/olethread.cxx:61:
> Thread is in a main single-threaded apartment.
> 
> Searching "CoInitializeEx" gives:
> https://opengrok.libreoffice.org/
> search?project=core&full=CoInitializeEx&defs=&refs=&path=&hist=&type=&si=full
> some code use: "COINIT_MULTITHREADED"
> other parts use: "COINIT_APARTMENTTHREADED"

The warning is likely innocent; and the two modes are expected. Mostly we need
COINIT_MULTITHREADED; but in case of AsyncRequests thread, we need
COINIT_APARTMENTTHREADED (because it's UI thread). That is set in
VistaFilePickerImpl::before - see comments there. So that thread has an
specific mode; possibly that's why DLLs loaded from it are released when it's
uninitialized ... the question is how to terminate the dialog properly =
terminate secondary (tertiary) thread with the windows.storage.dll processing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191121/e57b8402/attachment-0001.html>