Download it now!
Bug 53533 - shlxthdl_x64.dll/shlxthdl.dll causes Windows Explorer to CRASH when corrupted ODF file is in view
Summary: shlxthdl_x64.dll/shlxthdl.dll causes Windows Explorer to CRASH when corrupted...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other Windows (All)
: medium normal
Assignee: Fridrich Strba
URL:
Whiteboard: target:3.7.0 target:3.6.2
Keywords:
: 53833 55171 55598 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-08-15 10:43 UTC by Andras Timar
Modified: 2013-03-22 10:45 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Timar 2012-08-15 10:43:35 UTC
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.
Comment 1 Björn Michaelsen 2012-08-20 22:32:11 UTC
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?
Comment 2 Andras Timar 2012-08-21 19:53:57 UTC
>	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()
Comment 3 Andras Timar 2012-08-23 18:39:10 UTC
*** Bug 53833 has been marked as a duplicate of this bug. ***
Comment 4 Not Assigned 2012-08-27 14:11:05 UTC
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
Comment 5 Not Assigned 2012-08-27 14:51:27 UTC
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.
Comment 6 Jared 2012-08-30 17:52:29 UTC
(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.
Comment 7 Rainer Bielefeld Retired 2012-10-05 04:31:12 UTC
*** Bug 55171 has been marked as a duplicate of this bug. ***
Comment 8 Rainer Bielefeld Retired 2013-03-22 10:45:32 UTC
*** Bug 55598 has been marked as a duplicate of this bug. ***