Apache OpenOffice (AOO) Bugzilla – Issue 125519
CRASH when step through document from page to page
Last modified: 2016-08-30 21:29:56 UTC
Steps how to reproduce with AOO411m6(Build:9775) - Rev. 1617669 2014-08-13 09:06:54 (Mi, 13 Aug 2014) (from German install.exe) 1. Open <http://www.bielefeldundbuss.de/OOO_QA/sample20.odg> What also has been sample document for "Issue 123478 - CRASH when applying lots of color properties changes to greyscale raster graphics" 2. In Navigator step forward from page to page using rightarrow icon in top bar of navigator (it does not matter whether you use Side Bar Navigator or Normal Navigator) > After 4 steps or so AOO will crash without visible reason like Memory usage or so. Was OK with 4.1.0 Many documents are affected, best reproducible with documents > 10 pages and scanned elements. I do not know what exactly in the documents is the reason for the crash. Crash is not limited to Navigator-Stepping, also other page changes or edits cause a crash.
I can confirm the crash for AOO420m1(Build:9800)-Rev. 1620195 and for AOO411m6(Build:9775)-Rev. 1617669 2014-08-13 09:06:54 (Mi, 13 Aug 2014) For me it looks like a memory problem. Open the Windows Task-Manager and watch the free physical memory. I have extended the example document with some photos to make the problem more obvious. In default memory settings, 20MB are reserved. When you go down the document from page to page, you can watch the free physical memory decreasing, with crash around around 24MB. OpenOffice becomes more stable, when you increase the Graphics cache to its maximum of 256MB. But it still crashes, not always with the first slides but somewhere in the additional photos. I get the most stable behavior - but still crashes sometimes - when I set the "remove from memory" time to its minimum of 00:01 hh:mm. Of cause in this case it takes 1-2 seconds for each picture till it is loaded when you switch to another page. I confirm, that there is no crash in AOO410m18(Build:9764)-Rev. 1589052 2014-04-22 11:43:54 (Di, 22 Apr 2014). @Rainer: It is nice that you have not totally retired.
I also see a crash in AOO410m14(Build:9760) - Rev. 1583418 Rev.158341, but with that version (and identical memory settings like in 4.1.1) much more steps are required.
Checked and it indeed is a problem. It only happens on win, on 32bit, with the pro version and when starting AOO *without* the debugger. Thus it comes up late for AOO411 which is sad. I hate Win to be so able to survive accesses to freed memory. I want apps to crash reliably in this case! Problem was to find out what happens when you cannot use the debugger. Slowly advancing (by intuition :-{) I found that there is a potential problem in GraphicManager::ImplCheckSizeOfSwappedInGraphics() which is the new method I added to limit the used mem for GraphicObjects/GraphicManager for 32bit systems. It collects GraphicObjects and swaps them out (oldest first) until the limit is okay again. I added a check if the next candidate to swap out is still existent (GraphicObjects have bad runtime existance control), and see there: It rarely sometimes happens that it is deleted. Argh! This must happen by an earlier call to FireSwapOutRequest in the same loop. This means that this call at GraphicObject A *may* somehow delete a GraphicObejct B, probably by triggering waiting events or whatever other stuff in the GraphicManger surroundings. If GraphicObject B is younger as A and the limit is still too high it may happen that B->FireSwapOutRequest() is called at a destroyed B which is an error and should crash (but does often not on windows). The good thing is that this seems not to happen very often; you need big graphic files to reah the limit and you will need several ones on one page (so that not a single one needs swap out but a bunch of them). For completeness (not a serious suggestion): AOO411 running in the debugger will not crash, thus being a theoretical workaround (sigh).
.
Re-checked this change and committed. Question is what to do now - it's hard to say how often this might happen. On one side it happens on the 32bit pro version without debugger, this is the Win7 version 75-80% are using. On the other side it needs multiple big graphics, more than one per side. It's still hard to guess how probable it is to happen. I saw one complaint until now in dev list (Openoffice 4.1.1 constant crashes) which might be related.
> On one side it happens on the 32bit pro version without debugger, > this is the Win7 version 75-80% are using i can confirm crash on win 7 64 bit too
@brinzing: 32bit was related to AOO, not to OS.
You may have a look at Issue 125567 (Impress). Similar problem during a slideshow : random crash when changing slide through buttons. The slides contain many images.
"alg" committed SVN revision 1621730 into trunk: i125519 check GraphicObject existance before accessing it
"alg" committed SVN revision 1682743 into branches/AOO410: #125519# applied fix for branch AOO410
Okay, fix added to branch AOO410 for AOO412
This was already discussed on the dev list back in May, and the fix was already committed both to trunk and to the 4.1.2 ("AOO410") branch by Armin back then. Marking as release blocker for clarity, but no further actions are needed.
Confirmed fixed with AOO412m1(Build:9780) - Rev. 1705625 2015-09-28 12:45:04 (Mo, 28 Sep 2015) under Windows XP Pro x86 SP3
Closing.