Bug 102688 - Crash in: vcl::Window::dispose()
Summary: Crash in: vcl::Window::dispose()
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: high critical
Assignee: Kohei Yoshida
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.1
Keywords:
: 87204 102524 105376 105522 (view as bug list)
Depends on:
Blocks: GDI-Limit
  Show dependency treegraph
 
Reported: 2016-09-27 20:14 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2017-07-10 19:04 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["vcl::Window::dispose()"]


Attachments
zip-file with the 2 spreadsheet documents opened when the error has occured (1.49 MB, application/zip)
2016-09-27 20:14 UTC, Stefan_Lange_KA@T-Online.de
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2016-09-27 20:14:22 UTC
Created attachment 127684 [details]
zip-file with the 2 spreadsheet documents opened when the error has occured

This bug was filed from the crash reporting server and is br-99f39f3c-d8fa-4241-816d-69b0fd50229d.
=========================================
LO version at this crash: LO 5.2.2.2 rc
I have opened 2 spreadsheet documents (see attachement)to commpare them and adjust the contents. In the course of this I have changed cell contents and added resp. changed comments in both documents. One of the documents I have succesfully saved, but when I have tried the save the other, LO has crashed.

The error can be reproduced:
- open both documments from attached zip-file
- "Alte Fotoapparate.ods", sheet "Altix IV und V", column D (Gehäuse-Nr.): change any cell contents
- save the document and keep it opened
- "altix_Nummern_aktuell_bearb_Lange.ods", sheet "Altix IV und V", column R (Herkunft), any cell with comment: show the comment, change it and then hide it 
- save the document --> LO crashes

same crash with LO 5.2.2.2 rc:
2e6428c1-6244-4b6e-9a66-df89651b7c31 

same crashes with LO 5.2.2.1 rc:
76bdf670-ccbf-4e4c-b171-7f219852da4e
43a34fb3-6a6b-4a64-8530-0df5eead6cec
a957d8de-3907-4b98-8639-21a7093c7c8f
180e60f8-9678-4104-8f8f-beec5f67c62d

also chrashed without a crash report on 2 computers with 
Version: 5.3.0.0.alpha0+
Build ID: a4c974293e84685aa055922b70b2470fcff2d844
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-27_01:01:30
Locale: de-DE (de_DE); Calc: group
Comment 1 Xisco Faulí 2016-09-27 20:37:01 UTC
*** Bug 102524 has been marked as a duplicate of this bug. ***
Comment 2 Aron Budea 2016-09-27 22:30:32 UTC
Reproduced with v5.2.2.2 / Windows 7.
Crash report: http://crashreport.libreoffice.org/stats/crash_details/2ad51e54-9370-4485-aa21-7a4057574e6a
v5.2.1.2 / Ubuntu 16.04 hung on me (it was just a VM using 1 core, but still).

I opened both spreadsheets (it was rather slow, the spreadsheets are large), tried to save both without any edits, got the crash.
Not a convenient reproduction, but reproduction nonetheless.
Comment 3 fiftyigfuci_f_mi 2016-09-28 20:36:32 UTC
When I only opened the "Alte Fotoapparate.ods", Calc spits out many error message like this:

warn:legacy.osl:26135:1:xmloff/source/core/xmlerror.cxx:178: An error or a warning has occurred during XML import/export!
Error-Id: 0x20040003
    Flags: 2 ERROR
    Class: 4 API
    Number: 3
Parameters:
    0: CharEscapementHeight
Exception-Message: UNKNOWN_PROPERTY
Position:
    Public Identifier: 
    System Identifier: file:///home/**/Desktop/Alte%20Fotoapparate.ods
    Row, Column: 2,10086945

The column number 10086945 is definitely extraordinary one.
Something goes wrong on opening the file.
Comment 4 Mike Kaganski 2016-10-01 03:06:50 UTC
(In reply to fiftyigfuci_f_mi from comment #3)
> warn:legacy.osl:26135:1:xmloff/source/core/xmlerror.cxx:178: An error or a
> warning has occurred during XML import/export!
> Position:
>     Row, Column: 2,10086945

The row/column number in this case is character position in XML: line 2, char 10086945. It has nothing to do with Calc column, though wording may be confusing.
Comment 5 Michael Meeks 2016-11-26 15:57:37 UTC
Reproduced it; the stack trace is small - and comes from some nt.dll!ExecuteHAndler and some __CxxFrameHAndler3(EHExceptionRecord *pExcept...) - which looks funky =)

I assume that we die in the middle of creating a FrameWindow - which (after all) will consume system resource handles. I imagine we die before we've chained ourselves into the list of top-level windows (at least the start of that list maWinData.mpFirstFrame is non-NULL and valid) - I assume it is quite long.

However - it does indeed seem that the root cause of this problem is using 10,000 GDI handles up; I wonder how we manage to do that ! =)
Comment 6 Michael Meeks 2016-11-26 16:04:10 UTC
http://www.nirsoft.net/utils/gdi_handles.html shows that we have:

Pen: 5
ExtPen: 0
Brush: 42
Bitmap: 2518
Font: 2471
Palette: 1
Region: 10
DC: 2522
Metafile DC: 0
Enhanced Metafile DC: 0
Other GDI: 0
GDI total: 0
All GDI: 10000

Though since the numbers don't full add-up, (only 7560?) thats rather interesting - but we get the idea: Bitmaps, Fonts, and DCs are the problem ... interesting.

The exception message on the console is:

"Could not create system bitmap!"

And also: 

vcl/win/gdi/salvd.cxx:114: CreateCompatibleDC failed: The operation completed succesfully
vcl/win/gdi/salvd.cxx:67: CreateDIBSection failed: the parameter is incorrect
vcl/win/window/salframe.cxx:442: CreateWindowExW failed: The operation completed successfully.

which is fun; prolly some good pointers there for breakpoints ...
Comment 7 Michael Meeks 2016-11-26 16:07:10 UTC
We start with a blank writer with 88 "All GDI" handles. During load / progress rendering of the first sheet we have ~105 - after load 162.
Comment 8 Michael Meeks 2016-11-26 23:25:17 UTC
Interesting; so the big blow out in handle creation is from:

 	editenglo.dll!VclPtr<VirtualDevice>::Create<>() Line 138	C++
>	editenglo.dll!ImpEditEngine::SetRefDevice(OutputDevice * pRef) Line 196	C++
 	editenglo.dll!ImpEditEngine::ImpEditEngine(EditEngine * pEE, SfxItemPool * pItemPool) Line 158	C++
 	editenglo.dll!EditEngine::EditEngine(SfxItemPool * pItemPool) Line 97	C++
 	editenglo.dll!OutlinerEditEng::OutlinerEditEng(Outliner * pEngOwner, SfxItemPool * pPool) Line 39	C++
 	editenglo.dll!Outliner::Outliner(SfxItemPool * pPool, OutlinerMode nMode) Line 1261	C++
 	svxcorelo.dll!SdrOutliner::SdrOutliner(SfxItemPool * pItemPool, OutlinerMode nMode) Line 33	C++
 	svxcorelo.dll!SdrMakeOutliner(OutlinerMode nOutlinerMode, SdrModel & rModel) Line 371	C++
 	svxcorelo.dll!SdrOutlinerCache::createOutliner(OutlinerMode nOutlinerMode) Line 49	C++
 	svxcorelo.dll!SdrModel::createOutliner(OutlinerMode nOutlinerMode) Line 1919	C++
 	svxcorelo.dll!SvxTextEditSourceImpl::GetBackgroundTextForwarder() Line 558	C++
 	svxcorelo.dll!SvxTextEditSourceImpl::GetTextForwarder() Line 725	C++
 	svxcorelo.dll!SvxTextEditSource::GetTextForwarder() Line 1029	C++
 	svxcorelo.dll!SvxShapeText::getString() Line 4025	C++
 	sclo.dll!ScShapeObj::getString() Line 1255	C++
 	xolo.dll!XMLShapeExport::collectShapeAutoStyles(const com::sun::star::uno::Reference<com::sun::star::drawing::XShape> & xShape) Line 306	C++
 	sclo.dll!ScXMLExport::CollectShapesAutoStyles(short nTableCount) Line 638	C++
 	sclo.dll!ScXMLExport::ExportAutoStyles_() Line 2536	C++
 	xolo.dll!SvXMLExport::ImplExportAutoStyles() Line 1185	C++
 	xolo.dll!SvXMLExport::exportDoc(xmloff::token::XMLTokenEnum eClass) Line 1444	C++
 	sclo.dll!ScXMLExport::exportDoc(xmloff::token::XMLTokenEnum eClass) Line 5036	C++
 	xolo.dll!SvXMLExport::filter(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aDescriptor) Line 840	C++
 	sclo.dll!ScXMLExport::filter(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aDescriptor) Line 5075	C++
 	sclo.dll!ScXMLImportWrapper::ExportToComponent(const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext, com::sun::star::uno::Reference<com::sun::star::frame::XModel> & xModel, com::sun::star::uno::Reference<com::sun::star::xml::sax::XWriter> & xWriter, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aDescriptor, const rtl::OUString & sName, const rtl::OUString & sMediaType, const rtl::OUString & sComponentName, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aArgs, ScMySharedData * & pSharedData) Line 688	C++
 	sclo.dll!ScXMLImportWrapper::Export(bool bStylesOnly) Line 918	C++
 	sclo.dll!ScDocShell::SaveXML(SfxMedium * pSaveMedium, const com::sun::star::uno::Reference<com::sun::star::embed::XStorage> & xStor) Line 527	C++
 	sclo.dll!ScDocShell::SaveAs(SfxMedium & rMedium) Line 1737	C++
 	sfxlo.dll!SfxObjectShell::SaveAsOwnFormat(SfxMedium & rMedium) Line 3052	C++
 	sfxlo.dll!SfxObjectShell::SaveTo_Impl(SfxMedium & rMedium, const SfxItemSet * pSet) Line 1426	C++
 	sfxlo.dll!SfxObjectShell::DoSave_Impl(const SfxItemSet * pArgs) Line 2530	C++
 	sfxlo.dll!SfxObjectShell::Save_Impl(const SfxItemSet * pSet) Line 2604	C++
 	sfxlo.dll!SfxBaseModel::storeSelf(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aSeqArgs) Line 1572	C++
 	sfxlo.dll!SfxStoringHelper::GUIStoreModel(const com::sun::star::uno::Reference<com::sun::star::frame::XModel> & xModel, const rtl::OUString & aSlotName, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgsSequence, bool bPreselectPassword, const rtl::OUString & _aSuggestedName, SignatureState nDocumentSignatureState) Line 1421	C++
 	sfxlo.dll!SfxObjectShell::ExecFile_Impl(SfxRequest & rReq) Line 650	C++
 	sfxlo.dll!SfxStubSfxObjectShellExecFile_Impl(SfxShell * pShell, SfxRequest & rReq) Line 197	C++
 	sfxlo.dll!SfxShell::CallExec(void (SfxShell *, SfxRequest &) * pFunc, SfxRequest & rReq) Line 214	C++
 	sfxlo.dll!SfxShell::ExecuteSlot(SfxRequest & rReq, const SfxInterface * pIF) Line 442	C++
 	sclo.dll!ScTabViewShell::ExecuteSave(SfxRequest & rReq) Line 735	C++

It seems that the default reference device is created left & right here.
Comment 9 Michael Meeks 2016-11-26 23:31:42 UTC
Hmm - so - interestingly; I suspect this intersects with Tor's commit:

https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=f218110744

I -suspect- that this reference device serves rather little purpose here beyond being a place-holder for map-modes, DPI details etc. and that the change:

     if ( !pRef )
-        pRefDev = EE_DLL().GetGlobalData()->GetStdRefDevice();
+    {
+        pRefDev = new VirtualDevice;
+        pRefDev->SetMapMode( MAP_TWIP );
+        bOwnerOfRefDev = true;

While no doubt safer in the pre-VclPtr past - where the whole lifecycle here was a witches brew of utter evil ;-) We could now have a reasonably safe VclPtr that we could get from VCL itself (and dispose during shutdown) - (in fact we have a static VirtualDevice cache that seems to work in the drawinglayer).

Anyhow - this would seem to mean that we cease allocating an expensive OS VirtualDevice for each and every EditEngine that is created - which in turn -should- fix this bug and a lot of others around resource starvation on windows =)
Comment 10 Stefan_Lange_KA@T-Online.de 2016-11-26 23:54:41 UTC
If you have made your test with the files I have attached to the bug:
I have first wondered about crash because of bitmaps. But in the sheet document "Alte Fotoapparate.ods" are not only web links but also links to picture files on my computer. These links I hadn't in my mind when I have attached the files. I can send the pictres when needed.
But I cannot imagine that the missing picture files really cause the crash, because I get the crash too, although the pictures are present.
And when I understand the comments until #9 correctly there is already an idea about the reaL reason of the crash.
Comment 11 Michael Meeks 2016-11-28 09:30:58 UTC
The fix is an intelligent revert of Tor's patch - of that I'm sure; and it is likely that it causes a number of other similar issues wherever we have lots of EditEngine's ...
Comment 12 Kohei Yoshida 2017-01-26 02:16:42 UTC
I've tested this with a build that contains the fix for Bug 103927, and didn't get the crash.  I'm pretty sure this one is fixed by the same fix for the other bug.  But someone else confirming would be great.
Comment 13 Stefan_Lange_KA@T-Online.de 2017-01-26 13:44:03 UTC
Test with
Version: 5.4.0.0.alpha0+
Build ID: b41186a2fc49e440890b8c86e5367352ffaf9cd6
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-26_01:50:40
Locale: de-DE (de_DE); Calc: group

I have tested as described in Comment 2 from Aaron Budea (no changes, only save), first with GDI quota increased to 60000 and then with the default quota 10000. I have watched the GDI counter with Nirsoft DIView.

Result:
No crashes, GDI counter increases only slightly while files were saved. OK!

But while the tests I have also "played": opened one or both spreadsheets and only scrolled in the sheets without making any changes.
I have seen in GDIView, that GDI counter increases very fast and finally exceeds the limit + Crash of LO.
This behavior is not reproducible with LO 5.3.0 RC2,
not with LO 5.3.1.0.0+ Time: 2017-01-26_08:58:36
and also not with LO 5.4.0.0.alpha0+ Time 2017-01-24_23:36:57

Therefore I can't exclude that this behavior is related to the new fix.
Comment 14 Kohei Yoshida 2017-01-27 03:48:18 UTC
Yup, VirtualDevice instances are leaking, which indirectly caused GDI resource leak too.
Comment 15 Commit Notification 2017-01-27 04:38:49 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fab2f546d1fb3ceaf5ee5d4d728f1728a8f1e7f3

tdf#102688: prevent leaking of VirtualDevice instances.

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2017-01-27 20:44:53 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2f6d11e35cdd09291e730429d6c876532f34328

tdf#102688: let's purge it here just in case...

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Kohei Yoshida 2017-01-27 20:45:24 UTC
It should be good now.  Please test.
Comment 18 Kohei Yoshida 2017-01-27 20:47:21 UTC
*** Bug 87204 has been marked as a duplicate of this bug. ***
Comment 19 V Stuart Foote 2017-01-28 18:08:19 UTC
*** Bug 105376 has been marked as a duplicate of this bug. ***
Comment 20 Stefan_Lange_KA@T-Online.de 2017-01-29 14:40:39 UTC
Test with
Version: 5.4.0.0.alpha0+
Build ID: e073bb9c3ea2f7d03a7cf0759efc70edf84fc033
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-29_05:25:38
Locale: de-DE (de_DE); Calc: group

I have tested as described in Comment 2 from Aaron Budea (no changes, only save), first with GDI quota increased to 60000 and then with the default quota 10000. I have watched the GDI counter with Nirsoft GDIView.

Result:
No crashes, GDI counter increases only slightly while files were saved. OK!

The problem, that GDI counter increases alreaady while scrolling without making any changes, no longer exists.

After this I have repeated the test as desribed in Comment_15 of Bug 87204: I have tried to open at the same time the 4 documents attached to Bug 102688 (2x ods), Bug 105118 (foo.odp) and Bug 87204 (0-Einleitung.pps).
Depending on the sequence how documents were opened, there were several problems.
These problems do not exist in LO 5.3.0 RC3, when GDI quota is is increased e.g. on 60000, but in the same or in a similar form already in LO 5.4.0.0.alpha0+ Time 2017-01-24_23:36:57, that means before the first patch of Kohei Yoshida. Therefore I think, the problems aren't related to these patches. I wil report a new bug.
Comment 21 Kohei Yoshida 2017-01-30 22:23:28 UTC
Thanks.  With that, I'll finally mark this bug as fixed.
Comment 22 Stefan_Lange_KA@T-Online.de 2017-02-01 18:10:38 UTC
Will the patch also be pushed to LO 5.3.1?
Comment 23 Stefan_Lange_KA@T-Online.de 2017-02-11 17:56:51 UTC
Can it be, that the patch was pushed to LO 5.3.1, although there is no notice about?

In LO 5.3.0 the error still occurs (GDI counter increases, LO chrashes, when the GDI Limit is exceeded), but I have made a test with the attached both test files (spreadsheet documents) with

Version: 5.3.1.0.0+
Build-ID: 076aea2fc77ab37172797ecec5d70f3e9ee8b38f
CPU-Threads: 1; BS-Version: Windows 6.2; UI-Render: Standard; Layout-Engine: neu; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2017-02-10_13:08:28
Gebietsschema: de-DE (de_DE); Calc: Group

Result: No crash, GDI counter doesn't increase while Save!
Comment 24 Aron Budea 2017-02-11 20:20:29 UTC
Thanks for bringing it up. It must've been this commit:

author		Kohei Yoshida <kohei.yoshida@collabora.com>	2017-01-24 03:01:37 (GMT)
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2017-02-01 13:29:27 (GMT)
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-3&id=48168ced891de8e4eca6fd1eb490c452534fccd2
"tdf#103927: Share single standard VirtualDevice instance.

To avoid creating excessive amounts of VirtualDevice instances. Also, since we now have VclPtr, we shouldn't need this bOwnerOfRefDev flag.

This fixes tdf#102688 as well as other GDI-Limit related issues. See tdf#105469 for other bugs this may fix.

(cherry picked from commit b41186a2fc49e440890b8c86e5367352ffaf9cd6)
(cherry picked from commit fab2f546d1fb3ceaf5ee5d4d728f1728a8f1e7f3)
(cherry picked from commit bac2baa785ffc75160de2d15da60901152da33de)"
Comment 25 Stefan_Lange_KA@T-Online.de 2017-02-22 20:00:32 UTC
Test OK too with 
Version: 5.3.1.1 (x64)
Build-ID: 72fee18f394a980128dc111963f2eefb05998eeb
CPU-Threads: 4; BS-Version: Windows 6.19; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 26 Xisco Faulí 2017-07-10 19:04:43 UTC
*** Bug 105522 has been marked as a duplicate of this bug. ***