Bug 116803 - Crash on third file opening
Summary: Crash on third file opening
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2018-04-04 15:46 UTC by Telesto
Modified: 2018-11-29 10:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
sample file (1.46 MB, application/vnd.oasis.opendocument.presentation)
2018-04-10 22:02 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-04-04 15:46:18 UTC
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
Comment 1 Buovjaga 2018-04-10 19:42:19 UTC
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
Comment 2 Xisco Faulí 2018-04-10 22:02:19 UTC
Created attachment 141274 [details]
sample file
Comment 3 Xisco Faulí 2018-04-10 22:40:22 UTC
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
Comment 4 Xisco Faulí 2018-05-08 13:51:02 UTC
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
Comment 5 Tomaz Vajngerl 2018-05-20 12:14:19 UTC
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.
Comment 6 Tomaz Vajngerl 2018-05-21 00:48:45 UTC
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.
Comment 7 Tomaz Vajngerl 2018-05-21 02:48:21 UTC
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..
Comment 8 yuchun 2018-11-29 08:16:46 UTC
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
Comment 9 Telesto 2018-11-29 08:55:45 UTC
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
Comment 10 Xisco Faulí 2018-11-29 10:00:29 UTC
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!!