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.
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
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
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?
(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.
Created attachment 126630 [details] File that causes crash when saving as Impress file
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.
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)
*** Bug 101989 has been marked as a duplicate of this bug. ***
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.
bug 98163 is a similar sort of problem
crashreport.libreoffice.org/stats/crash_details/2ffbde74-81d8-46ba-939c-daf4310d8cd4 Signature vcl::Window::dispose()
Created attachment 127989 [details] backtrace master 5.3 from Windbg.txt
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.
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?
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.
(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?
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.
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.
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.
(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
Attachment 126630 [details] and attachment 127217 [details] are not valid OOXML files, tested with Open XML SDK 2.5 Productivity Tool.
(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
I've tested this with a build that contains fix for Bug 103927, and I can't reproduce the crash.
Someone please test and confirm this. If not, I'll assume it is fixed.
Confirm it fixed with current master. Thanks Kohei!