*** Bug 102524 has been marked as a duplicate of this bug. ***

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.

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.

(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.

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 ! =)

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 ...

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.

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.

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 =)

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.

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 ...

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.

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.

Yup, VirtualDevice instances are leaking, which indirectly caused GDI resource leak too.

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.

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.

It should be good now.  Please test.

*** Bug 87204 has been marked as a duplicate of this bug. ***

*** Bug 105376 has been marked as a duplicate of this bug. ***

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.

Thanks.  With that, I'll finally mark this bug as fixed.

Will the patch also be pushed to LO 5.3.1?

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!

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)"

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

*** Bug 105522 has been marked as a duplicate of this bug. ***