https://bugs.documentfoundation.org/show_bug.cgi?id=95579
Michael Stahl <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|regression |
Status|UNCONFIRMED |NEW
CC| |[email protected]
Hardware|Other |x86 (IA32)
Ever confirmed|0 |1
--- Comment #11 from Michael Stahl <[email protected]> ---
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".
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
