Issue 125519 - CRASH when step through document from page to page
Summary: CRASH when step through document from page to page
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: 4.1.1
Hardware: All Windows 7
: P3 Normal (vote)
Target Milestone: 4.1.2
Assignee: AOO issues mailing list
QA Contact:
Keywords: regression
Depends on:
Reported: 2014-08-26 17:28 UTC by Rainer Bielefeld
Modified: 2016-08-30 21:29 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
pescetti: 4.1.2_release_blocker+


Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2014-08-26 17:28:13 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 <>
   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.
Comment 1 Regina Henschel 2014-08-26 19:20:41 UTC
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.
Comment 2 Rainer Bielefeld 2014-08-28 07:26:25 UTC
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.
Comment 3 Armin Le Grand 2014-08-28 09:24:55 UTC
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).
Comment 4 Oliver Brinzing 2014-08-28 12:53:46 UTC
Comment 5 Armin Le Grand 2014-09-01 10:40:22 UTC
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.
Comment 6 Oliver Brinzing 2014-09-01 16:26:44 UTC
> 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
Comment 7 Armin Le Grand 2014-09-03 09:30:14 UTC
@brinzing: 32bit was related to AOO, not to OS.
Comment 8 bmarcelly 2014-09-12 06:53:42 UTC
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.
Comment 9 SVN Robot 2014-10-07 09:44:21 UTC
"alg" committed SVN revision 1621730 into trunk:
i125519 check GraphicObject existance before accessing it
Comment 10 SVN Robot 2015-05-31 15:30:17 UTC
"alg" committed SVN revision 1682743 into branches/AOO410:
#125519# applied fix for branch AOO410
Comment 11 Armin Le Grand 2015-05-31 15:31:35 UTC
Okay, fix added to branch AOO410 for AOO412
Comment 12 Andrea Pescetti 2015-07-11 07:43:22 UTC
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.
Comment 13 Pedro 2015-10-09 11:43:16 UTC
Confirmed fixed with

AOO412m1(Build:9780)  -  Rev. 1705625
2015-09-28 12:45:04 (Mo, 28 Sep 2015)

under Windows XP Pro x86 SP3
Comment 14 Kay 2016-08-30 21:29:56 UTC