Download it now!
Bug 101327 - Impress crashes saving a pptx doc
Summary: Impress crashes saving a pptx doc
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.2.4 target:5.3.0.1
Keywords: notBibisectable, preBibisect, regression
: 101989 (view as bug list)
Depends on:
Blocks: GDI-Limit
  Show dependency treegraph
 
Reported: 2016-08-05 16:34 UTC by Eric
Modified: 2017-02-07 09:50 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["vcl::Window::dispose()"]


Attachments
File that causes crash when saving as Impress file (1.39 MB, application/vnd.openxmlformats-officedocument.presentationml.presentationa)
2016-08-06 14:32 UTC, Eric
Details
backtrace master 5.3 from Windbg.txt (10.54 KB, text/plain)
2016-10-13 17:14 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric 2016-08-05 16:34:29 UTC
Downloaded Libre Office. New Laptop running Windows 10. Opened a pptxfile: 60 pages,text only, 1.4mb.  Can't save the file: tried as a pptx file, error message 'Write error,file could not be written'.  Tries as an odg file and it crashes Libre Office, every time.
Comment 1 mahfiaz 2016-08-05 17:14:03 UTC
Could you please upload the example document which causes this behavior?

Or could you take a look if any of these resemble your case?
https://bugs.documentfoundation.org/buglist.cgi?list_id=626056&query_format=advanced&resolution=---&short_desc=crash%20save&short_desc_type=allwordssubstr
Comment 2 Julien Nabet 2016-08-05 17:16:55 UTC
Which LO version did you download?
Last stable one 5.1.4.

Could you take a look and apply advice quoted here:
https://wiki.documentfoundation.org/QA/FirstSteps
Comment 3 Eric 2016-08-05 17:40:43 UTC Comment hidden (obsolete)
Comment 4 Julien Nabet 2016-08-05 21:44:28 UTC
(In reply to Eric from comment #3)
> V 5.2.0.4.
> You say last stable version was 5.1.4 but default Still version on your
> website is 5.1.5? Which is best?

My fault, 5.1.5 is now the last stable one. Sorry for this.
Comment 5 Eric 2016-08-06 14:32:01 UTC
Created attachment 126630 [details]
File that causes crash when saving as Impress file
Comment 6 MM 2016-08-06 17:30:13 UTC
Confirmed with v5.1.5.2 under windows 7 x64.
Saving it to pptx, LO says the file can't be written, then crashes. Saving to odp just crashes without error.
Comment 7 Julien Nabet 2016-08-07 11:24:57 UTC
A backtrace may be useful (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace for retrieving it on Windows)
Comment 8 Caolán McNamara 2016-09-23 15:12:31 UTC
*** Bug 101989 has been marked as a duplicate of this bug. ***
Comment 9 Caolán McNamara 2016-09-23 15:13:39 UTC
I believe the underlying problem here is the same as bug 101327. Maybe we are exhausting the number of virtual devices we can have alive at the same time under windows.
Comment 10 Caolán McNamara 2016-09-23 15:19:12 UTC
bug 98163 is a similar sort of problem
Comment 11 Timur 2016-10-13 17:02:12 UTC
crashreport.libreoffice.org/stats/crash_details/2ffbde74-81d8-46ba-939c-daf4310d8cd4

Signature vcl::Window::dispose()
Comment 12 Timur 2016-10-13 17:14:02 UTC
Created attachment 127989 [details]
backtrace master 5.3 from Windbg.txt
Comment 13 Mike Kaganski 2016-10-19 03:34:27 UTC
This started somewhere before Version: 4.1.0.0.beta2
Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6

The stated version already crashes saving attachment 126630 [details] as ODG, while 4.0.6.2 does not -> regression, preBibisect.

No crash with Version: 5.2.2.2
Build ID: 1:5.2.2-0ubuntu1~xenial0
CPU Threads: 1; OS Version: Linux 4.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group

No bibisect repository for that commit range for Windows -> notBibisectable.

The initial crash (on current master) happens in void vcl::Window::dispose() at line 547 of vcl/source/window/window.cxx:
> pSysWin = pSysWin->mpWindowImpl->mpFrameData->mpNextFrame;

because pSysWin happens to be nullptr.
Actually, all the block starting from line 539:
> if ( mpWindowImpl->mbFrame )
fails because it tries to use mpWindowImpl->mpFrame and mpWindowImpl->mpFrameData, that are both nullptr for some reason.

If line 539 is fixed this way:
> if ( mpWindowImpl->mbFrame && mpWindowImpl->mpFrame && mpWindowImpl->mpFrameData )
then next crash happens in ::std::shared_ptr<FrameworkHelper> FrameworkHelper::Instance (ViewShellBase& rBase) at line 333 of sd/source/ui/framework/tools/FrameworkHelper.cxx:
> InstanceMap::const_iterator iHelper (maInstanceMap.find(&rBase));
This time, it turns out that static maInstanceMap gets cleared somewhere previously, but somehow incorrectly, so that its size is 0, but _Myhead's _Mytop, _Myleft and _Myright members do not point to _Myhead but to 0xdddddddd, and _Myproxy is 0x00000000 (in essence, maInstanceMap is ruined), so find() segfaults.
Comment 14 Mike Kaganski 2016-10-19 05:02:19 UTC
The stack trace of a point at which the static member seems to be ruined is this:

 	sdlo.dll!std::_Tree<std::_Tmap_traits<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > >,0> >::clear() Line 1543	C++
 	sdlo.dll!std::_Tree<std::_Tmap_traits<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > >,0> >::erase(std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > > > > _First, std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > > > > _Last) Line 1515	C++
 	sdlo.dll!std::_Tree<std::_Tmap_traits<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > >,0> >::_Tidy() Line 2230	C++
 	sdlo.dll!std::_Tree<std::_Tmap_traits<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > >,0> >::~_Tree<std::_Tmap_traits<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > >,0> >() Line 1193	C++
 	sdlo.dll!std::map<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > > >::~map<sd::ViewShellBase *,std::shared_ptr<sd::framework::FrameworkHelper>,std::less<sd::ViewShellBase *>,std::allocator<std::pair<sd::ViewShellBase * const,std::shared_ptr<sd::framework::FrameworkHelper> > > >()	C++
 	sdlo.dll!`dynamic atexit destructor for 'sd::framework::FrameworkHelper::maInstanceMap''()	C++
 	sdlo.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 416	C
 	sdlo.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 522	C
 	sdlo.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 472	C
 	ntdll.dll!77a7dbbe()	Unknown

Seems like the DLL is loaded second time (presumably to save Impress file as ODG - i.e. loading Draw module for that) and re-writes the variable?
Comment 15 Mike Kaganski 2016-10-19 06:59:37 UTC
Actually, something happens with lo that it calls FatalError( exUNO.Message) in its desktop::Desktop::Main(). This unloads all libraries. That's when I see the static member destruction. Maybe execution of code after that is just a debugging artifact.
Comment 16 Mike Kaganski 2016-10-19 15:36:07 UTC
(In reply to Caolán McNamara from comment #9)
> I believe the underlying problem here is the same as bug 101327. Maybe we
> are exhausting the number of virtual devices we can have alive at the same
> time under windows.

We definitely do. The number of GDI objects is exactly 10 000 at the time of failure to create a new VirtualDevice in WinSalInstance::CreateVirtualDevice(SalGraphics*, long&, long&, DeviceFormat, const SystemGraphicsData*)

See https://blogs.technet.microsoft.com/markrussinovich/2010/03/31/pushing-the-limits-of-windows-user-and-gdi-objects-part-2/

Interesting, is that a leak or a usage pattern?
Comment 17 Commit Notification 2016-11-26 22:23:59 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=115671bf929a82709c535b475bf19f4967a666c8

tdf#101327 - tolerate exceptions during window construction better.

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2016-11-28 11:27:24 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=77b65e3e7ae04f6f00f2cadda9fd80176fe0dec1&h=libreoffice-5-2

tdf#101327 - tolerate exceptions during window construction better.

It will be available in 5.2.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2016-11-28 11:40:51 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c8bfac5329741530f7cb2740246dbd11449fb74&h=libreoffice-5-3

tdf#101327 - tolerate exceptions during window construction better.

It will be available in 5.3.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Yuri Konotopov 2017-01-09 08:25:39 UTC
(In reply to Commit Notification from comment #18)
> Michael Meeks committed a patch related to this issue.
> It has been pushed to "libreoffice-5-2":
...
> 
> It will be available in 5.2.4.
> 

Version 5.2.4 did not fixed issue for me with attachment from bug 101989
Comment 21 Timur 2017-01-09 10:56:59 UTC
Attachment 126630 [details] and attachment 127217 [details] are not valid OOXML files, tested with Open XML SDK 2.5 Productivity Tool.
Comment 22 Yuri Konotopov 2017-01-09 11:16:24 UTC
(In reply to Timur from comment #21)
> Attachment 126630 [details] and attachment 127217 [details] are not valid
> OOXML files, tested with Open XML SDK 2.5 Productivity Tool.

It's a bug in the tool [1]

[1] http://openxmldeveloper.org/discussions/formats/f/14/p/8638/164880.aspx#164880
Comment 23 Kohei Yoshida 2017-01-26 02:40:02 UTC
I've tested this with a build that contains fix for Bug 103927, and I can't reproduce the crash.
Comment 24 Kohei Yoshida 2017-01-27 20:50:29 UTC
Someone please test and confirm this.  If not, I'll assume it is fixed.
Comment 25 Mike Kaganski 2017-01-27 21:02:55 UTC
Confirm it fixed with current master. Thanks Kohei!