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
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?
Created attachment 69848 [details] impress file caused crashes replay to julien
Created attachment 69849 [details] creating blank impress file caused a crash after a fresh boot
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.
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.
(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!
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.
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?
Yes, please zip the buggy LO user directory and attach it to the bugtracker.
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
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”.
@ 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.)
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.
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.
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.
@ 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!
(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.
*** Bug 57650 has been marked as a duplicate of this bug. ***
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.
Committed a patch that removes the invalid masterpages from view and doesn't crash.
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.
Patch to solve this accepted
The content of attachment 69939 [details] has been deleted