This is a follow-up of bug 52078. Bug 53420 might be related. Windows Explorer shell extension of LibreOffice works with ODF files. However, if ODF file is corrupted, shell extension's code could not tolerate it, and crashes with unhandled exception error. Just rename any non-ODF file to .odt for example. It can be triggered with a Flat ODF file for sure.
Just taking a longshot here: If there was gbuild migration involved (as bug 52078) suggests, it might be that now more object files are compiled with exception support as gb_Library_add_noexception_objects are the rare exception now (pun intended). If so, maybe in dmake something was build without exception support and the 'unhandled exception' was then eaten by a grue?
> shlxthdl_x64.dll!`anonymous namespace'::findCentralDirectoryEnd(StreamInterface * stream=0x00000000029d9040, long & startOffset=1222650696) Line 264 C++ shlxthdl_x64.dll!ZipFile::GetDirectory() Line 501 + 0xd bytes C++ shlxthdl_x64.dll!ZipFile::HasContent(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & ContentName={...}) Line 526 + 0xd bytes C++ shlxthdl_x64.dll!CThumbviewer::Extract(HBITMAP__ * * phBmpImage=0x000000000c895f10) Line 371 + 0xf bytes C++ thumbcache.dll!000007fef22a9ff4() [Frames below may be incorrect and/or missing, no symbols loaded for thumbcache.dll] thumbcache.dll!000007fef22a93df()
*** Bug 53833 has been marked as a duplicate of this bug. ***
Fridrich Å trba committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3300205918f87054c9dd399ac53ad1e979dcdc7 fdo#53533: don't seek to bogus offset
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=93a65b34adb99baea96aa85b7854aec2cf071647&g=libreoffice-3-6 fdo#53533: don't seek to bogus offset It will be available in LibreOffice 3.6.2.
(In reply to comment #1) > Just taking a longshot here: If there was gbuild migration involved (as bug > 52078) suggests, it might be that now more object files are compiled with > exception support as gb_Library_add_noexception_objects are the rare exception > now (pun intended). > > If so, maybe in dmake something was build without exception support and the > 'unhandled exception' was then eaten by a grue? I've found a similar crash (not using flat-ODF) when I have an ODT file open on a Linux computer and a Windows client simply browses to the directory in which I have that file open. If I close the ODT on my Linux (OpenSUSE 12.1 XFCE) computer, and close LibreOffice I can browse through Windows Explorer to that directory again.
*** Bug 55171 has been marked as a duplicate of this bug. ***
*** Bug 55598 has been marked as a duplicate of this bug. ***