Issue 107248 - Free render picture before killing underlying drawable
Summary: Free render picture before killing underlying drawable
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOO310m19
Hardware: Unknown Unix, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: thb
QA Contact: issues@gsl
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-11-26 21:03 UTC by thb
Modified: 2017-05-20 10:29 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Proposed fix (2.59 KB, patch)
2009-11-26 21:04 UTC, thb
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description thb 2009-11-26 21:03:22 UTC
See $subject. E.g. crashes for me with RenderBadPicture in *frame.cxx's
createNewWindow, currently triggerable when leaving Writer's fullscreen mode on
a xinerama display.
Comment 1 thb 2009-11-26 21:04:09 UTC
Created attachment 66366 [details]
Proposed fix
Comment 2 2009-11-27 07:42:21 UTC
+1, thanks!
The first chunk of the patch is for fixing the crash, the other chunks are a minor optimization?
Comment 3 thb 2009-11-27 10:41:03 UTC
@hdu: no. :)
Comment 4 2009-11-27 10:45:59 UTC
@thb: should this issue have an OOo32 target then? It is probably a regression since I haven't seen 
anything in that area in the OOo31x stacktraces. Was it introduced by issue 103145?
Comment 5 thb 2009-11-27 11:41:24 UTC
@hdu: did not do extended archeology here, but my hunch is, since this happens
exclusively in that one xinerama setup I had for fixing issue 107249, and *not*
for slideshow fullscreen window (as probably because that one goes fullscreen
immediately, so there's no Picture allocated yet), it's simply quite unlikely to
happen (assuming not many people use writer fullscreen mode in conjunction with
multi-monitor setups).

regarding 3.2: sure, would gladly have it in there, if you think it's something
RSM would agree on I'll ask on releases@
Comment 6 2009-11-27 12:31:17 UTC
> [...] this happens exclusively in that one xinerama setup I had for fixing issue 107249
> [...] it's simply quite unlikely to happen

Then an OOo320 target is quite unlikely so late in the game; especially as the changes for issue 107249 
will not get into that release. On the other hand the patch seems general enough so that other scenarios 
might be fixed too. Anyway if there are such scenarios and you get the nod from the release manager feel 
free to join the latest ooo32gsl* CWS.
Comment 7 uwe.luebbers 2009-11-27 16:54:37 UTC
Adjusted target
Comment 8 thb 2009-11-27 17:45:32 UTC
Fixed in CWS ooo32gsl08.
Comment 9 philipp.lohmann 2009-11-30 16:22:21 UTC
When changing the signature of a virtual method in a base class it is usually
recommended to change the derived classes, too :-(

Will change updateGraphics accordingly.
Comment 10 philipp.lohmann 2009-11-30 16:35:14 UTC
GRmpf, sorry. I see now that the attached patch is not what you checked in.
Forget what I said.
Comment 11 philipp.lohmann 2009-11-30 17:21:08 UTC
Now working on a updated copy I noticed that indeed the original patch was taken
and both KDE plugins were now missing the correct updateGraphics. Fixed and
committed in CWS ooo32gsl08.
Comment 12 philipp.lohmann 2009-12-01 10:17:20 UTC
please verify in CWS ooo32gsl08
Comment 13 thb 2009-12-01 23:21:19 UTC
@pl: good catch, thx. Verified changes in CWS, though I don't find the "
updateGraphics(true)" more self-explanatory than " updateGraphics(None)". Anyway.
Comment 14 philipp.lohmann 2009-12-02 10:15:01 UTC
It's not meant to be self explanatory ;-). updateGraphics was intended as "put
you current state into all used graphics"; state in this case always being
window and screen number. Passing the window handle as parameter is half baked
in this regard; we would have to pass the screen also. However what is currently
needed is only a set/unset kind of use, so a bool will do.