I can open file with Version: 5.1.0.0.alpha1+
Build ID: 9a85743766e8a063d20d5f93ee88758e243397f4
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-10-23_00:56:39

I can open file with Version: 5.1.0.0.alpha1+ (x64)
Build ID: b35e797ca0e2c7e7ad6dbccea6b92208b209677c
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-11-02_22:21:21
and Version: 5.1.0.0.alpha1+
Build ID: c5fefe46fc9dca3942b2fc33ffd1f7e041d450e6
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-11-04_07:04:49

Can open it, but once, closing it after scrolling to the last page, I got a fatal error. Could not reproduce it though..

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 37d41674c2b1a706c95c2c326cbfbd06b0c1a655
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-02_00:13:27
Locale: fi-FI (fi_FI)

Mine is Version: 5.1.0.0.alpha1+
Build ID: 6744951cf9b911dc1ac516b06c0363b80de36c3f
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-03_22:14:59
Locale: hr-BA (hr_BA)

Created attachment 121500 [details]
debug from LO 5.2a0

I add 2 debug reports from  LO 5.2a0, hopefully someone will find it useful.

Mike, I was free to add you to CC. 
I cannot open the file with master nor 5.1.0, but we have different reports here, though.

This one is weird. I open it with 5.1.1.3 although very slowly, and I get crash with 5.2+ master: mergedlo.dll SfxViewShell.

I had crash with this file. File open, but after scroll I get error message: osl::thread::create failed.Version: 5.2.0.0.alpha0+ (~10 days old build);win7

But this crash I can not reproduce again...

crashreport.libreoffice.org/stats/crash_details/e5972ac7-39ac-4fe3-bc5f-633e3e710f77

Another report without the data - how comes this?
crashreport.libreoffice.org/stats/crash_details/4dac86c2-79c0-4fca-9cf1-bbd7f2cb2a11

i don't get a SEH exception but the crash from comment #9,
"osl::Thread::create failed".

the document contains a lot of OLE objects of type "Equation.DSMT4"
which is a MathType version that our Math doesn't support yet
(only versions up to 3 are supported),
so they cannot be converted on import.

OpenIStorageFromURL_Impl calls StgOpenStorage for each of them
and that allocates 4MB of virtual memory, of which only 20kb or
so are actually committed because the objects are small.

all of these OLE object allocations eat 1GB of VM, and together
with the rest of the allocations this brings us very close
to the 2GB VM limit on Win32, and thus there isn't enough
contiguous VM left to allocate a 9MB thread stack for every CPU
when spinning up the comphelper threadpool.

the thread pool is used to scale bitmaps in VCL.

i'm not sure how exactly this was working in older versions...
the substantial problem is the 4MB of VM per OLE object in
LOADED state and that code doesn't look changed recently.

for comparison i've looked at a 4.3.7.2 release build and it
has the same 1GB VM for OLEs; the total VM usage is a little
lower than debug build of current master but if you insert 20 more
OLEs you will get the same problem; thus i'm removing "regression".

i guess the best approach here is "use the 64-bit build".

Should this stay open then (what could be done? increase the limit?) or closed as WontFix?
Looks like there should be a bug for MathType 4 support, Bug 33590 can be the one.

i don't see an easy way to fix it; possibly our OLE wrapper class could be changed to use our own temp-files to store the OLE object and only "load" it on demand and then "unload" it again, but that looks like a rather large change and who knows what performance issues it could cause...