Crash on third file opening. Might be a dupe of bug 116798
Steps to Reproduce:
1. Open file https://mycore.core-cloud.net/index.php/s/7f0dIa5aYgyVrtd (bug 116798)
2. Close it with the gray cross (back to start center)
3. Attempt to open the file again (failing)
4. Try to opening a different document from Star Center -> Crash
User Profile Reset: No
Build ID: 03a6be9dda966a8d16f271480c7be0d6d69ee39e
CPU threads: 4; OS: Windows 6.3; UI render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2018-04-03_23:11:47
Locale: nl-NL (nl_NL); Calc: CL
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
attachment 141147 [details]
Repro on Win, not on Lin.
No yet happening in 6.0.3. 6.0 also opens it much faster.
Version: 220.127.116.11.alpha0+ (x64)
Build ID: d39a8e791618a40328c0f90bece3cc246dcf57f7
CPU threads: 4; OS: Windows 10.0; UI render: default;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-06_00:59:07
Locale: fi-FI (fi_FI); Calc: group
Created attachment 141274 [details]
Regression introduced by:
author Tomaž Vajngerl <firstname.lastname@example.org> 2018-02-13 21:49:57 +0900
committer Tomaž Vajngerl <email@example.com> 2018-02-14 07:47:26 +0100
commit 1b02ba03bd62a712e15c15384a3d105d2c088120 (patch)
parent 733d77570771e2536d5ce1f18ba82f68ac6c22ee (diff)
shapes: don't use "GraphicURL" property, always use "Graphic"
With GraphicURL property on shapes (XShape) we transported the
external or internal URL to the model, which also included the
GraphicObject uniqueID style URLs. This changes that - now we
always use "Graphic" property and transfer XGraphic to and from
graphic filters. "Graphic" property is already present for XShape
so it wasn't needed to add it.
Filters changed are: OOXML (oox), ODF (xmloff), RTF and
binary MS (esherex).
Also start using originURL on Graphic which now transports the
URL of the external (linked) graphic/image if it was created that
Bisected with: bibisect-win32-6.1
Adding Cc: to Tomaž Vajngerl
Still reproducible in
Build ID: 638ec7728b9a1327b424eade7f6bc5828b575921
CPU threads: 16; OS: Windows 6.3; UI render: default;
Locale: en-GB (en_GB); Calc: group
Oh crazy.. a EMF/WMF image takes 9600 GDI handles and the limit per process in 10000 handles. After the document is closed, the GDI handles aren't released, which is what I'm trying to track why exactly, but this won't fix the issue with the image itself.
OK so.. the exact scenario doesn't happen with LO 6.0 but by third opening it alos crashes because of 10000 open GDI handles. So this is not directly a problem with the image handling rework, it just made the behaviour of the crash a bit different.
In LO 6.0 the GDI handles also aren't cleared when the document is closed, so it clearly is a GDI handle leak we have in EMF/WMF code somewhere (or somewhere else but triggered by EMF/WMF import code). I'll try to find the source of the leak but it is clear that the bug is miscategorized.
the EMF file has 4747 bitmaps and all of them need to be loaded to render the file (at elast this is how we do it now). Changing that would need to involve quite some thinking..
Bug not reproducible in version.
Version: 18.104.22.168.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
No repro either
Build ID: f21d2b48bd68424a96aa6cd5572e368208378291
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win;
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-27_00:26:54
Locale: en-US (nl_NL); UI-Language: en-US
Yes, it seems to be fixed in
Id. de compilación: 86daf60bf00efa86ad547e59e09d6bb77c699acb
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.;
Configuración regional: es-ES (es_ES); Calc: group threaded