Bug 95579 - Writer SEH Exception on DOCX with MathType, OLE object allocations of 4MB of VM per OLE close to 2GB VM limit on Win32
Summary: Writer SEH Exception on DOCX with MathType, OLE object allocations of 4MB of...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: x86 (IA32) Windows (All)
: lowest major
Assignee: Not Assigned
Keywords: haveBacktrace
Depends on:
Reported: 2015-11-04 18:10 UTC by Timur
Modified: 2017-05-17 07:36 UTC (History)
5 users (show)

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

debug from LO 5.2a0 (13.54 KB, text/plain)
2015-12-22 17:32 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2015-11-04 18:10:19 UTC
Testing attachment 116737 [details] from Bug 67450, LO 5.1+ master 2015-11-03 doesn't open the file (seh exception: access violation), while LO does.
Comment 1 raal 2015-11-04 19:39:49 UTC
I can open file with Version:
Build ID: 9a85743766e8a063d20d5f93ee88758e243397f4
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-10-23_00:56:39
Comment 2 raal 2015-11-04 19:58:45 UTC
I can open file with Version: (x64)
Build ID: b35e797ca0e2c7e7ad6dbccea6b92208b209677c
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-11-02_22:21:21
and Version:
Build ID: c5fefe46fc9dca3942b2fc33ffd1f7e041d450e6
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-11-04_07:04:49
Comment 3 Buovjaga 2015-11-04 20:01:47 UTC
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:
Build ID: 37d41674c2b1a706c95c2c326cbfbd06b0c1a655
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-02_00:13:27
Locale: fi-FI (fi_FI)
Comment 4 Timur 2015-11-04 20:16:41 UTC
Mine is Version:
Build ID: 6744951cf9b911dc1ac516b06c0363b80de36c3f
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-03_22:14:59
Locale: hr-BA (hr_BA)
Comment 5 Timur 2015-12-22 17:32:39 UTC
Created attachment 121500 [details]
debug from LO 5.2a0

I add 2 debug reports from  LO 5.2a0, hopefully someone will find it useful.
Comment 6 Timur 2016-01-22 09:19:07 UTC
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.
Comment 7 Timur 2016-03-29 18:22:25 UTC
This one is weird. I open it with although very slowly, and I get crash with 5.2+ master: mergedlo.dll SfxViewShell.
Comment 8 raal 2016-03-31 06:42:36 UTC
I had crash with this file. File open, but after scroll I get error message: osl::thread::create failed.Version: (~10 days old build);win7

But this crash I can not reproduce again...
Comment 9 Timur 2016-08-23 17:36:47 UTC
Comment 10 Timur 2016-09-20 07:07:50 UTC
Another report without the data - how comes this?
Comment 11 Michael Stahl (allotropia) 2016-09-30 21:38:28 UTC
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 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".
Comment 12 Timur 2016-10-05 07:02:31 UTC
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.
Comment 13 Michael Stahl (allotropia) 2016-10-05 08:57:48 UTC
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...
Comment 14 Timur 2016-10-05 09:05:46 UTC Comment hidden (obsolete)