Description: 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 Actual Results: Crash Expected Results: No Crash Reproducible: Always User Profile Reset: No Additional Info: Version: 6.1.0.0.alpha0+ 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: 6.1.0.0.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] sample file
Regression introduced by: author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2018-02-13 21:49:57 +0900 committer Tomaž Vajngerl <quikee@gmail.com> 2018-02-14 07:47:26 +0100 commit 1b02ba03bd62a712e15c15384a3d105d2c088120 (patch) tree b46f383c7ea60de65dbbede5b658a7babd813610 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 way. Bisected with: bibisect-win32-6.1 Adding Cc: to Tomaž Vajngerl
Still reproducible in Version: 6.1.0.0.alpha1+ 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: 6.3.0.0.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 Calc: threaded
No repro either Version: 6.3.0.0.alpha0+ 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 Calc: CL
Yes, it seems to be fixed in Versión: 6.1.3.2 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 Nice!!