Download it now!
Bug 106282 - Crash in: windows.storage.dll when hitting cancel in file open dialog, when a file search is running
Summary: Crash in: windows.storage.dll when hitting cancel in file open dialog, when a...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: File-Dialog Crash
  Show dependency treegraph
 
Reported: 2017-03-02 14:35 UTC by ich01
Modified: 2020-05-16 19:45 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["windows.storage.dll"]


Attachments
Backtrace of crash with 5.4 (5.78 KB, text/plain)
2017-03-05 19:32 UTC, Buovjaga
Details
Drmemory trace (4.51 KB, text/plain)
2017-03-08 17:13 UTC, Buovjaga
Details
Drmemory false positives (1.03 MB, text/plain)
2017-03-23 15:08 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ich01 2017-03-02 14:35:37 UTC
This bug was filed from the crash reporting server and is br-7274a047-8ab7-42ee-9d2f-c002362c1134.
=========================================

Hi there!
Got this crash after trying to insert a new image via "Image" > "Insert" menu. I was using the search function of the file picker, let it search for a long time and then I canceled the search and closed the window without selecting a file. Right after that, LibreOffice crashed.

As I don't think that the opened document is relevant, I will not include it here. Nevertheless, please ask if it is necessary.

While the crash happened, I had two windows with two separate documents open.
Comment 1 ich01 2017-03-02 14:44:41 UTC
Did some further testing. Here are a few tips to reproduce:

Bug only happens, if you search in a big folder (for example your drive top directory) and when it is still searching when you click "Cancel" (and when there are no results yet).
Bug does not depend on the document, even happens in empty file.
Comment 2 Xisco Faulí 2017-03-02 15:25:41 UTC
Hello ich01,

Thank you for reporting the bug.
I can't reproduce it in

Versión: 5.3.0.3
Id. de compilación: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
Subpr. de CPU: 1; Versión de SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; 
Configuración regional: es-ES (es_ES); Calc: group

on Win 7 x86
Comment 3 ich01 2017-03-02 15:40:25 UTC
Maybe it'll help if I add a step-by-step description of how to reproduce:

1. Open a new Document in LibreOffice Writer
2. Click "Insert" > "Image" (filepicker opens)
3. Go to the top directory of your hard drive (or a similar big folder that takes long enough to search)
4. Type some text in the search box in the top right corner (maybe something random, crash happens only when no items get displayed and it is still searching).
5. Click cancel while it is still looking for files and hasn't found something yet, otherwise crash won't happen.
(6.) (It looks like the cursor moves a bit to the right, like a TAB, but I'm not sure about that)

--> Crash

If you still can't reproduce, maybe your version/OS is not affected(?), I'm on Windows 10 using the version I selected above in the bug report.

Application and System Info:
Build:  0312e1a284a7d50ca85a365c316c7abbf20a4d22
CPU-Threads: 6; BS-Version: Windows 6.2; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 4 Buovjaga 2017-03-05 19:32:56 UTC
Created attachment 131658 [details]
Backtrace of crash with 5.4

Version: 5.4.0.0.alpha0+
Build ID: a5c947579253a7f4e784004e18929af5ab22fa28
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-03-02_01:57:01
Locale: fi-FI (fi_FI); Calc: group
Comment 5 Michael Meeks 2017-03-08 10:00:27 UTC
120efaec 65d32aa0 10599858 10599870 120efb18 explorerframe!CFirstPageResults::RunBackgroundEnumeration+0xf5
120efb28 75546bb8 0ff95b78 00000000 104cd4f0 explorerframe!CFirstPageTask::InternalResumeRT
120efb44 778be82c 7476ce4b 00000000 00000000 windows_storage!CShellTaskScheduler::_MT_QueueTaskInPriorityOrder+0x3b
120efb64 75547816 10599858 0a2b3680 104cd4f0 ntdll!NtQueryInformationThread+0xc
120efbb4 7765cff2 75546740 09f26510 120efbd8 windows_storage!CShellTask::TT_Run+0x49

Looks like internal / Microsoft Windows symbols; not code that we produce. Of course - possibly we corrupt memory so that this happens. Any chance of trying the same thing under 'DrMemory' ? so we can get a trace ? It looks like destroying the file dialog doesn't clean up its running background threads.

Can you reproduce this in some other application like notepad ?
Comment 6 Buovjaga 2017-03-08 17:13:12 UTC
Created attachment 131758 [details]
Drmemory trace

This is what I got..
Comment 7 Buovjaga 2017-03-09 18:44:18 UTC
(In reply to Michael Meeks from comment #5)
> Can you reproduce this in some other application like notepad ?

Tried with Notepad - Open dialog. No crash.
Comment 8 Michael Meeks 2017-03-23 11:01:40 UTC
Thanks for the drmemory trace - but it looks very short =) It is necessary to rename 'soffice.bin' to 'soffice_real.exe' and run drmemory on that I suspect to get a good drmemory trace: did you do that ? =)

The trace looks like for the soffice.exe factory wrapper.

Thanks !
Comment 9 Buovjaga 2017-03-23 11:29:50 UTC
(In reply to Michael Meeks from comment #8)
> Thanks for the drmemory trace - but it looks very short =) It is necessary
> to rename 'soffice.bin' to 'soffice_real.exe' and run drmemory on that I
> suspect to get a good drmemory trace: did you do that ? =)
> 
> The trace looks like for the soffice.exe factory wrapper.

I did it according to the instructions, which no not mention the necessity: https://wiki.documentfoundation.org/Development/How_to_debug#Searching_for_a_memory_corruption_on_Windows_using_DrMemory

I will try again.
Comment 10 Buovjaga 2017-03-23 15:08:11 UTC
Created attachment 132103 [details]
Drmemory false positives

Now it said 0 errors, but lots of false positives, so I'm attaching a txt file with them.

Version: 5.4.0.0.alpha0+
Build ID: a5c947579253a7f4e784004e18929af5ab22fa28
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-03-02_01:57:01
Locale: fi-FI (fi_FI); Calc: group
Comment 11 Julien Nabet 2019-05-10 13:39:31 UTC
On Win10 + master sources updated today, I don't reproduce this.

Any update with a recent LO version?
Comment 12 Buovjaga 2019-05-10 13:59:22 UTC
(In reply to Julien Nabet from comment #11)
> On Win10 + master sources updated today, I don't reproduce this.
> 
> Any update with a recent LO version?

Still repro with steps from comment 3. Build is from 25 April (for some reason the date is not shown in About anymore).

Version: 6.3.0.0.alpha0+
Build ID: 951282a27a9dd4c64fc206fcbdd805b4cb602816
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded
Comment 13 Julien Nabet 2019-09-10 13:24:08 UTC
Just for the record, I made another test with master sources updated today, I tried with openGL enabled then disabled, no repro in both cases.

Also, I use Win10, version 1709 (16299.1331), it's not my machine so can't update myself.
Comment 14 Buovjaga 2019-09-17 18:11:14 UTC
Still crashing with steps in comment 3

Version: 6.4.0.0.alpha0+ (x64)
Build ID: bda1d88f2bfa21202725ab9c567b3cccba3c1f0b
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-15_04:18:20
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded
Comment 15 Oliver Brinzing 2019-11-09 16:35:08 UTC
still reproducible with:

Version: 6.4.0.0.alpha1+ (x64)
Build ID: a79640b30ae08087224931bac832bb2d5c9c542a
CPU threads: 12; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded


Win10 x64 1903 Build 18362.449
Comment 16 Oliver Brinzing 2019-11-10 15:49:53 UTC
even AOO 4.1.5 will crash, but no crash with other programs e.g. Firefox, Acrobat Reader etc.

will crash in ExplorerFrame.dll:

Version: 6.4.0.0.alpha1+ (x64)
Build ID: 5ae8f2f07815443716b3066706b4f193fe61f7c9
CPU threads: 12; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: CL

Name der fehlerhaften Anwendung: soffice.bin, Version: 6.4.0.0, Zeitstempel: 0x5dc5a036
Name des fehlerhaften Moduls: explorerframe.dll_unloaded, Version: 10.0.18362.418, Zeitstempel: 0x619c47cc
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000014e107
ID des fehlerhaften Prozesses: 0x3d9c
Startzeit der fehlerhaften Anwendung: 0x01d597c71216de9b
Pfad der fehlerhaften Anwendung: D:\sources\libo-core\instdir\program\soffice.bin
Pfad des fehlerhaften Moduls: explorerframe.dll
Berichtskennung: 0958566f-f282-4d4f-ae54-bb94c79885b1
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 

crash happens after returning from:

filedlghelper.cxx:

ErrCode FileOpenDialog_Impl( weld::Window* pParent,
                             sal_Int16 nDialogType,
                             FileDialogFlags nFlags,
                             std::vector<OUString>& rpURLList,
                             OUString& rFilter,
                             std::unique_ptr<SfxItemSet>& rpSet,
                             const OUString* pPath,
                             sal_Int16 nDialog,
                             const OUString& rStandardDir,
                             const css::uno::Sequence< OUString >& rBlackList )
{
    [...]

    nRet = pDialog->Execute(rpURLList, rpSet, rFilter, aPath);
    DBG_ASSERT( rFilter.indexOf(": ") == -1, "Old filter name used!");

    if (rpSet && nFlags & FileDialogFlags::SignPDF)
        rpSet->Put(SfxBoolItem(SID_DOC_READONLY, true));
 *** CRASH ***
    return nRet;
}
Comment 17 Mike Kaganski 2019-11-21 11:35:46 UTC
The problem seems to be unloading of ExplorerFrame.dll in CoUninitialize() in the AsyncRequests thread, while still running the code from it (executing CFirstPageResults::RunBackgroundEnumeration - see comment 5).

However, simply removing CoUninitialize() from VistaFilePickerImpl::after() doesn't help, possibly because it still gets called automatically when the thread terminates (?).

Hope this would help.
Comment 18 Julien Nabet 2019-11-21 13:50:56 UTC
(In reply to Mike Kaganski from comment #17)
> The problem seems to be unloading of ExplorerFrame.dll in CoUninitialize()
> in the AsyncRequests thread, while still running the code from it (executing
> CFirstPageResults::RunBackgroundEnumeration - see comment 5).
> 
> However, simply removing CoUninitialize() from VistaFilePickerImpl::after()
> doesn't help, possibly because it still gets called automatically when the
> thread terminates (?).
>...

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"
Comment 19 Mike Kaganski 2019-11-21 14:26:15 UTC
(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.