Bug 56877 - FILEOPEN CRASH when "registrymodifications.xcu" contains an entry about "RecentlyUsedMasterPages" to be loaded from a file which does not exist
Summary: FILEOPEN CRASH when "registrymodifications.xcu" contains an entry about "Rece...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.6.3.2 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium critical
Assignee: Rob Snelders
URL:
Whiteboard: target:4.0.0
Keywords:
: 57650 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-08 13:56 UTC by eastasiax
Modified: 2018-02-26 11:20 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
after crashes, the collected infors to send to apple (59.28 KB, text/plain)
2012-11-08 13:56 UTC, eastasiax
Details
impress file caused crashes (1.17 MB, application/vnd.oasis.opendocument.presentation)
2012-11-10 03:52 UTC, eastasiax
Details
creating blank impress file caused a crash after a fresh boot (60.11 KB, text/plain)
2012-11-10 04:01 UTC, eastasiax
Details
crash report of libreoffice in new start osx lion (57.12 KB, text/plain)
2012-11-12 06:52 UTC, eastasiax
Details
old "usr" profile that caused impress crashed (deleted)
2012-11-12 12:18 UTC, eastasiax
Details
When I install eastasiax' "registrymodifications.xcu", I get this crash with LibO 3.6.3.2 (53.88 KB, text/plain)
2012-11-13 11:49 UTC, Roman Eisele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description eastasiax 2012-11-08 13:56:17 UTC
Created attachment 69699 [details]
after crashes, the collected infors to send to apple

Problem description: 
impress crashes when opening an exist file or start a new file. File and crash report will be attached. After crash Libre, there is a report windows,the info will be attached in a file 
Steps to reproduce:
1. .... double click to open a odp or ppt file, or open libre,start a new presentation
2. ....
3. ....

Current behavior:
inmpress/pesentation crashes

Expected behavior:
impress opens file and edit it.

Platform (if different from the browser): 
OSx 10.7.5
Comment 1 Julien Nabet 2012-11-09 23:53:56 UTC
Could you attach a file which triggers the crash?

According to the stacktrace, it seems you use CorelDraw drawing, do you confirm this? If yes, do you have some crashes if you don't use them?
Comment 2 eastasiax 2012-11-10 03:52:25 UTC
Created attachment 69848 [details]
impress file caused crashes

replay to julien
Comment 3 eastasiax 2012-11-10 04:01:16 UTC
Created attachment 69849 [details]
creating blank impress file caused a crash after a fresh boot
Comment 4 Julien Nabet 2012-11-10 15:26:10 UTC
eastasiax: thank you for your feedback.

On pc Debian x86-64 with master sources updated today, I don't reproduce the problem.
I'd like to test with 3.6 sources but I've got some problems with it for the moment.

Put back to Unconfirmed.
Comment 5 Roman Eisele 2012-11-11 09:06:44 UTC
Can not confirm the crash with LibreOffice 3.6.3.2 (Build ID: 58f22d5), German langpack installed, on Mac OS X 10.6.8 (Intel). For me, the presentation (attachment 69849 [details]) opens without any problems. Hm ... so this bug is also not always reproducible on Mac OS X.

Setting Severity to “critical”; please understand that normally we don’t understand “blocker”, not even for very critical bugs.
Comment 6 Roman Eisele 2012-11-11 10:36:02 UTC
(In reply to comment #3)
> Created attachment 69849 [details]
> creating blank impress file caused a crash after a fresh boot

Attachment 69849 [details] was, if the files have not been been exchanged, created for a crash which happened when “creating [a] blank impress file [...] after a fresh boot”. This is really strange. Reading the stack backtrace, the problem seems to be here, just like in the other (FILEOPEN) crash report:

...
7   libc++abi.dylib     0x9ba2a2a0 __cxa_throw + 112
8   libwpftdrawlo.dylib 0x2cdea042 libcdr::readU32(WPXInputStream*, bool) + 82
9   libwpftdrawlo.dylib 0x2cde6d02 libcdr::CMXDocument::
                                   isSupported(WPXInputStream*) + 50
10  libwpftdrawlo.dylib 0x2ccf7b27 CMXImportFilter::detect(com::sun::
                                   star::uno::Sequence<com::sun::star::
                                   beans::PropertyValue>&) + 263
...

So there seems to be an unhandled exception which is thrown from libcdr::readU32() inside of libwpftdrawlo.dylib. Hm ... According to
  http://cgit.freedesktop.org/libreoffice/libcdr/tree/src/lib/CMXDocument.cpp
the function CMXDocument::isSupported() does:
  “Analyzes the content of an input stream to see if it can be parsed
  \param input The input stream
  \return A value that indicates whether the content from the input
  stream is a Corel Draw Document that libcdr is able to parse.”
Now I wonder why, when “creating [a] blank impress file”, such a function is called -- why should we need Corel Draw support on creating a new blank presentation file?


@ Julien Nabet:
Can you please check, e.g. by adding some debug dump message to the code, if these functions from libcdr are normally called when creating a new Impress presentation file?


@ eastasiax:
Please check the following:

1) A thumb question first: Does this crash really happen when you just start your Mac, start LibreOffice, and create a new (empty) presentation? I know this is a thumb question, but I just want to prevent any misunderstandigs ...

2) There is a chance that this problem is cause by a corrupted LibreOffice user profile (= application settings etc.). Therefore, you should try if resetting your LibreOffice user profile helps to heal the problem.
To do so, please:
   a) Quit LibreOffice, if running.
   b) In the Finder, please open the folder
      <Your main drive>/Users/<Your user folder>/Library/Application Support/
   c) In this folder, there should be a folder called “LibreOffice”,
      which contains most LibreOffice settings (and therefore is called
      the “user profile folder”).
      Just rename this folder so something else, e.g. “LibreOffice-old”.
   d) Start LibreOffice again (the startup will take longer this time,
      because LibreOffice creates a fresh user profile).
   e) Test the issue again. Do you still see the crash?
Then please report the results in a new comment here ...

Thank you very much!
Comment 7 Julien Nabet 2012-11-11 13:12:27 UTC
Roman: on pc Debian x86-64 with 3.6 sources updated today I don't reproduce this bug.
About libcdr, I don't know how to do this since "make libcdr.clean && make libcd" recreates the cpp file and "make libcdr" seems not to take into account the change I do.
Comment 8 eastasiax 2012-11-12 06:52:25 UTC
Created attachment 69930 [details]
crash report of libreoffice in new start osx lion

@Roman
reboot osx lion 7.5, no other program opened, even no network, just open the libreoffic and create the new presentation, and off course, as expected, it crashed.

<rename this folder-"user" in osx lion.>
followed this steps, now impress works well. i don't know why. before this, all except impress work well. should i upload my "user" fold for finding this error specific to impress?
Comment 9 Julien Nabet 2012-11-12 07:09:57 UTC
Yes, please zip the buggy LO user directory and attach it to the bugtracker.
Comment 10 eastasiax 2012-11-12 12:18:06 UTC
Created attachment 69939 [details]
old "usr" profile that caused impress crashed

hi, there.
   i am glad to report any bug to improve libreoffce. hope this can help
Comment 11 Roman Eisele 2012-11-13 10:00:45 UTC
Thank you very much for attaching your old LibreOffice user profile!

With it, I can REPRODUCE the crash with LibreOffice 3.6.3.2 on my machine (with Mac OS X 10.6.8 Intel).

If I
1) reset my own LibreOffice user profile, to preclude any influence
   of local settings on the test:
   -- quit LibreOffice 3.6.3.2;
   -- rename ~/Library/Application Settings/LibreOffice
      to something else;
   -- start LibreOffice 3.6.3.2 again, to create a new user profile
      folder with default settings.
   -- quit LibreOffice again;
2) copy the file “registrymodifications.xcu” from eastasiax’ old user
   profile into my own (newly created) user profile folder;
3) start LibreOffice 3.6.3.2 again;
4) open eastasiax’ sample file “presentation_091001.odp”
   and wait a few seconds,

I get exactly the same crash as eastasiax -- I mean, a crash with exactly
the same stack backtrace.

So the problem is in the main settings file, “registrymodifications.xcu”.
Comment 12 Roman Eisele 2012-11-13 10:06:02 UTC
@ eastasiax:

Have you upgraded from some previous LibreOffice version? I want to know this, because it is possible that this bug is due to some update problem; I mean,
that “registrymodifications.xcu” was corrupted somehow in the update process.


@ Julien Nabet:
Could you please try if you can reproduce the crash also on pc Debian x86-64,
if you install eastasiax’ “registrymodifications.xcu” file?
(Then this would be a cross-platform problem; else, the crash would be specific
to LibreOffice for Mac OS X.)
Comment 13 Roman Eisele 2012-11-13 11:49:29 UTC
Created attachment 69993 [details]
When I install eastasiax' "registrymodifications.xcu", I get this crash with LibO 3.6.3.2



(In reply to comment #11)
> I get exactly the same crash as eastasiax -- I mean, a crash with exactly
> the same stack backtrace.

I have to correct myself here -- the topmost lines of the stack backtraces are different; but IMHO the important lines are identical, so the crash seems to have the same reasons.
Comment 14 Roman Eisele 2012-11-13 12:11:10 UTC
The crash (I refer myself always to the crash I have reproduced with eastasiax’ “registrymodifications.xcu” file installed, see comment #11) is related to the area “Master Pages” → “Recently Used” in the “Tasks” pane.

If I open eastasiax’ sample file with his “registrymodifications.xcu” file installed, the area “Master Pages” → “Recently Used” is opened and shows for a short moment a blank rectangle with the text “Erzeuge Vorschau” (i.e., “Generating preview”) -- then LibO crashes.

So the crash seems related to the generation of the preview for a recently used Impress master page. This would also match the function calls in the stack backtrace -- especially:
sd::toolpanel::controls::MasterPageContainer(),
sd::toolpanel::controls::TemplatePageObjectProvider()
SfxApplication::LoadTemplate()
SfxFilterMatcher::GuessFilter()
filter::config::TypeDetection()

The latter lines seem to indicate that LibreOffice tries to guess the file type of a recently used Master page. And by some unknown reason (is this the real bug?) it guesses that there is a CMX file involved, i.e. a “Corel Metafile Exchange” file; so LibO calls the CMXImportFilter; and when this filter tries to check if the file is supported (CMXDocument::isSupported()), it crashes, probably because there is no such file ... or whatever may be the reason.
Comment 15 Roman Eisele 2012-11-13 12:24:01 UTC
And this is the faulty line/entry from eastasiax’ “registrymodifications.xcu” file:

<item oor:path="/org.openoffice.Office.Impress/MultiPaneGUI/ToolPanel/RecentlyUsedMasterPages"><node oor:name="index_0" oor:op="replace"><prop oor:name="Name" oor:op="fuse"><value>blackboard</value></prop><prop oor:name="URL" oor:op="fuse"><value>file:///Users/eastasiax/Library/Application Support/LibreOffice/3/user/template/blackboard.otp</value></prop></node></item>

If I install eastasiax’ “registrymodifications.xcu” file, but delete this line before starting LibreOffice, everything seems to work fine -- no crash when opening the sample .odp file.

This line seems to confirm my guessings (see previous comment) about the reasons of this crash: the line points to a .otp file which contains the recently used master page, but this file does not exists on my machine. Of course, LibreOffice should not crash in this situation.


Please correct me (I am just a simple-minded bug wrangler), but I would guess that there are two bug or three problems (bugs) involved here:

1) If an entry in “registrymodifications.xcu” points to a recently used Impress master page (i.e., the entry begins with
   <item oor:path="/org.openoffice.Office.Impress/MultiPaneGUI/ToolPanel
   /RecentlyUsedMasterPages">),
LibreOffice should check if the file to which the entry points does really exists; but it seems that LibreOffice currently does not check correctly for this condition. To fix this bug, we just need to *ignore* (and remove) any “registrymodifications.xcu” entries pointing to non-existing master page documents.

2) If, by whatever reason, LibreOffice tries to load a master page from a file which does not exist, it seems to call the CMX files importer. This is obviously wrong.

3) Maybe an additional bug: If libcdr::readU32() tries to read from a file which does not exist, or: a stream which is invalid, it would be better if it would not just throw an exception which is not handled (as now), but if we could manage to produce a meaningful error message.
Comment 16 Roman Eisele 2012-11-13 12:34:21 UTC
@ Impress and libcdr experts:

Hi Rodo, Thorsten, and Fridrich,

this is a nice bug related to the loading of “Recently Used” master pages in Impress. If an entry in “registrymodifications.xcu” about RecentlyUsedMasterPages points to a file which does no longer exist (or has an invalid path), LibreOffice crashes due to an unhandled exception (at least on Mac OS X). This crash is related to the strange fact that LibreOffice, instead of ignoring attempts to load recently used master pages from files which do not (longer) exist, tries to read that not existing file with the CMX importer.

So please take a look at this bug report, especially at my analysis in comment #14 and comment #15. (If my analysis is wrong, please correct me, but nevertheless I hope that it will help you.)
And please try to fix this issue ... ;-)

Thank you very much!
Comment 17 eastasiax 2012-11-13 18:19:28 UTC
(In reply to comment #12)
> @ eastasiax:
> 
> Have you upgraded from some previous LibreOffice version? I want to know
> this, because it is possible that this bug is due to some update problem; I
> mean,
> that “registrymodifications.xcu” was corrupted somehow in the update process.
> 
◎Roman
yes, i update it from 3.6.2.1 to 3.6.3.2, i just deleted libreoffice in Applications, and drag new one into it.
Comment 18 Rob Snelders 2012-12-02 10:28:38 UTC
*** Bug 57650 has been marked as a duplicate of this bug. ***
Comment 19 Rob Snelders 2012-12-02 12:15:24 UTC
The problem is that when it can't find the template it creates a empty file and tries to read that:
core/sfx2/source/appl/appopen.cxx:400
if ( !aMedium.GetStorage( sal_True ).is() )

It should give sal_False as argument then the application doesn't crash anymore. Then it doesn't create the empty file anymore but simply returns that the file doesn't exist.

But it will still try to load the document multiple times a second. So now going to search how to stop that.
Comment 20 Rob Snelders 2012-12-02 14:28:38 UTC
Committed a patch that removes the invalid masterpages from view and doesn't crash.
Comment 21 Not Assigned 2012-12-04 12:52:30 UTC
Rob Snelders committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a9c83fa8ac7e94d7124889e760c7343ccf3c19b

fdo#56877 CRASH when profile contains invalid RecentlyUsedMasterpages



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 22 Rob Snelders 2012-12-10 20:14:44 UTC
Patch to solve this accepted
Comment 23 Xisco Faulí 2018-02-26 11:20:18 UTC
The content of attachment 69939 [details] has been deleted