https://issues.apache.org/ooo/show_bug.cgi?id=125519
Armin Le Grand <armin.le.gr...@me.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |ACCEPTED
CC| |armin.le.gr...@me.com
--- Comment #3 from Armin Le Grand <armin.le.gr...@me.com> ---
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).
--
You are receiving this mail because:
You are the assignee for the issue.
You are watching all issue changes.
