Issue 107763

Summary: fly in animation of tranparent object crashes OO
Product: Impress Reporter: micha137 <an>
Component: codeAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P2 CC: andre.schnabel, caolanm, hdu, issues, khirano, lohmaier, maand, markomlm, mdxonefour, ooo, prooobo-1x_work, stefan.weigel, thb, werbung
Version: OOO320m7Keywords: crash, regression
Target Milestone: OOo 3.2   
Hardware: Unknown   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 99999    
Attachments:
Description Flags
presentation file, second anim. crashes under m7
none
a fix none

Description micha137 2009-12-18 09:39:05 UTC
Open new presentation
draw rectangle
format area: some color and transparency 50%
mark rectangle
select animation fly in
-> already crashes in preview
always crashes in presentation mode

I tried to produce a sample file: If sample is created under 3.1.9, it plays
flawless under m7.
If I create sample file under DEV3.2_m7 , succeed in avoiding the preview, save
and reload, I get irreproducible behaviour. Sometimes crashes, sometimes works.
I will attach a slide from a presentation that always crashes on the animation
of a group object which contains transparent parts.
Comment 1 micha137 2009-12-18 09:43:48 UTC
Created attachment 66706 [details]
presentation file, second anim. crashes under m7
Comment 2 wolframgarten 2010-01-04 11:54:25 UTC
No problems under m8. Have you been asked to send a crash report? Did you
receive an error id?
Comment 3 micha137 2010-01-04 12:21:26 UTC
Same behaviour on my systems(ubuntu karmic) under m8.
On animation, openoffice just exits immediately(does not freeze). On restart of
Openoffice, recovery process is initiated and a message is displayed that an
error report has been created. Upon selecting next, document is just reopened,
error reporting routine is not started.
Comment 4 wolframgarten 2010-01-21 09:44:03 UTC
Reproducible, but only on a direct display. On a Virtual Machine it works fine.
I the terminal I get the following output:
X-Error: RenderBadPicture (invalid Picture parameter)
        Major opcode: 157
        Minor opcode: 7
        Resource ID:  0x2e0216c
        Serial No:    90291 (90291)
Reassigned.
Comment 5 clippka 2010-01-21 09:59:35 UTC
reassigned
Comment 6 parity 2010-01-28 06:38:14 UTC
I can reproduce this bug using:
Ubuntu Karmic Koala
OpenOffice 3.2RC4

The behaviour is nearly as described before:
Open new presentation
draw rectangle
format area: some color and transparency 50%
mark rectangle
select animation fly in
start presentation

-->
it flies in (while it is flying, it does not show its color)
since the presentation has only one slide in this example, the presentation ends
now OOo crashes
Comment 7 thb 2010-01-28 23:32:29 UTC
It's the (failed) attempt to use Xrender on a 1bpp pixmap.
X11SalGraphics::GetXRenderPicture() just assumes it can call
XRenderCreatePicture() on ~anything. Several places to catch that, for 3.2 I
opted for the simplest one.
Comment 8 thb 2010-01-28 23:33:27 UTC
Created attachment 67466 [details]
a fix
Comment 9 parity 2010-01-29 06:31:39 UTC
Does the fix also solve the crash in the Renaissance presentation?

See issue 108748.

Could it be integrated in 3.2.0? A crash during a professional presentation is
not wanted in a release, i suppose.

Comment 10 wolframgarten 2010-01-29 08:44:55 UTC
*** Issue 108748 has been marked as a duplicate of this issue. ***
Comment 11 wope 2010-01-29 09:09:18 UTC
add cc
Comment 12 philipp.lohmann 2010-01-29 09:45:58 UTC
Personally I'd say since we have the XRenderWrapper anyway, why not catch the
bit count in CreatePicture instead of the independent vcl layer ? Anyway, if it
fixes the problem, I'm fine with this, too, one could clean that up in DEV300
where time is a little less pressing.

@hdu: what's your take on this ?
Comment 13 hdu@apache.org 2010-01-29 10:17:26 UTC
@thb: thanks! I am fine with the patch if we need an ASAP fix. We just need to make sure that the other 
platforms such as WIN or OSX are not impacted by this change. Moving the check into the SalGraphics 
layer would be better as PL noted since AFAIK the non-Render platforms do not have problems with small 
bitmap depths.
Comment 14 phantomas 2010-01-29 10:50:44 UTC
I can't reproduce the bug on Windows XP with rc4
Comment 15 lohmaier 2010-01-29 11:55:24 UTC
an analysed issue with a patch doesn't "needmoreinfo", setting crash and 
regression keywords, crashes deserve P2
Comment 16 groucho266 2010-01-29 12:36:51 UTC
@pl: Please take over.
Comment 17 thb 2010-01-29 12:56:29 UTC
@parity: yep, looks fixed here with the patch

@phantomas: of course not - OS == linux

@hdu: at least gdi+ on a palette display exposed horrible bugs, last time I
checked. so it may be wise to keep it at that, for win & linux.
Comment 18 markomlm 2010-01-29 14:00:25 UTC
After one more hint of andre schnabel I've tested this on Solaris EDE x86 with
RC4 (wjre). I can reproduce the crash with this platform too :-(
Comment 19 philipp.lohmann 2010-01-29 16:07:41 UTC
fixed in CWS ooo321gsl02

setting target to 3.2
Comment 20 tommy27 2010-01-30 03:43:40 UTC
does this impied that we will have a 3.2 RC5 release?
Comment 21 philipp.lohmann 2010-01-30 12:06:32 UTC
I don't know whether that is decided yet.

@wg: please verify in CWS ooo321gsl02
Comment 22 parity 2010-01-31 07:43:32 UTC
I just found another impress-crash bug in issuetracker. Is the crash reason in 
issue 107107 the same as here?
Comment 23 andreschnabel 2010-01-31 09:02:28 UTC
isue 107107 is likely to be the same. The example there uses transparent objects
on master and custom animation for regular text.

example from 107107 should be tested with the fix.
Comment 24 wolframgarten 2010-02-01 14:27:10 UTC
Verified in CWS under Linux.
Comment 25 wope 2010-02-03 00:27:07 UTC
Verified in SuSE 11.2 and OOO320m12
Comment 26 andreschnabel 2010-02-03 06:59:55 UTC
ok on OOO320m12, RedHat Linux ->closed
Comment 27 andreschnabel 2010-02-03 08:37:05 UTC
*** Issue 107107 has been marked as a duplicate of this issue. ***