Run ooffice. Open a new spreadsheet. Right click on a column header and select Delete Columns. Note how ooffice exits. I have 2.2.1-18.1.fc8.
There seems to be an XError being generated somewhere, Try and use export SAL_IGNOREXERRORS=YES before launching calc from a terminal and see if that works around it for now.
Yes, that does seem to suppress the issue.
So there's some XError causing this, I need to track it down. More than likely something else in the dependency tree has changed triggering this, might not be an OOo bug, or it may be an old OOo bug recently uncovered. Playing around it seems to be something around right clicking to get popup menus
X-Error: RenderBadPicture (invalid Picture parameter) Major opcode: 154 Minor opcode: 7 Resource ID: 0x3800597 Serial No: 9507 (9507)
caolanm->ajackson: The F-7 OOo rpms don't show this on F-7, but do if installed on rawhide. Any quick ideas so what may have changed ?
There's basically zero difference between F7 and rawhide X at this point. What hardware is this with?
I have it with nv on "nVidia GeForce4 Ti 4200 Go AGP 8x" and "nVidia GeForce 6800 GS"
I see the same issue here with fc7 updates-testing and fc7, fc7 updates, and fc8 openoffice rpms. A crash happens every few times I right click on a column or row, but every time I delete a cell with the delete key (regardless of "Delete All" or any option.), or delete a column or row. The export seems to fix the problem. Video card is an Intel 915GM. Is there any any other debugging info I can provide?
*** Bug 244354 has been marked as a duplicate of this bug. ***
damn it. This certainly wasn't happening during f-7 development, Marek Matulka: what's your X driver ?
My video card is Nvidia Quadro NVS 110M (GPU 0) I am using latest nvidia drivers provided by freshprms.net repository and at first I thought the problem is in nvidia update to a new 100.x line of drivers, but it's not. I have checked also 'nv' driver and I have exactly the same behavior - OpenOffice crashes after several clicks (usually right click and any click is enough). The export trick works for me fine, but it's not handy :)
right, versions of cairo please ? The F-7 release was "cairo-1.4.4-1.fc7", what do the F-7 reporters of this have installed ?
I have a cairo-1.4.8-1.fc7 from Fedora 7 Test Updates
yeah, ok. Do the obvious and roll-back just cairo to the F-7 version. I believe that this crash has been triggered that single updated package
yep :) it solved a problem, with cairo 1.4.4 works fine and doesn't crash on double clicks :) Thanks for a quick help!
oky doky, even if this is an OOo problem we shouldn't push a cairo update for F-7 which breaks it. I'll try and track down what changed in cairo to cause this. And then maybe we can see who's broken. caolanm->behdad: Hold on the cairo F-7 update, unless you want an angry mob with pitchforks :-)
git diff 8ad30ccdb0a00701b15003edb2fe0cd4a8a9dfb7 88c6d25d4e53ddad6f3d465b2f5249c76a421b82 apparently triggers it
Created attachment 157155 [details] Ignore XErrors during deferred destruction It is possible for the application to destroy the Drawable associated with a Picture before cairo has the chance to process the deferred work queue - this causes an XError when we later attempt to call XRenderFreePicture.
*** Bug 244642 has been marked as a duplicate of this bug. ***
*** Bug 244964 has been marked as a duplicate of this bug. ***
*** Bug 245204 has been marked as a duplicate of this bug. ***
I'm plagued by this, can we at least push a replacement testing update ?
The current fix has serious performance penalties. We are working on a better fix upstream. I unpushed the update for now.
*** Bug 245235 has been marked as a duplicate of this bug. ***
*** Bug 245464 has been marked as a duplicate of this bug. ***
Created attachment 157916 [details] Avoid deferring resource cleanup for application drawables An alternative approach that avoids the requirement for XSyncs. Patch relative to cairo-1.4.8.
Created attachment 157947 [details] Avoid deferring resource cleanup for application drawables An alternative approach that avoids the requirement for XSyncs. Patch relative to cairo-1.4.8.
*** Bug 245910 has been marked as a duplicate of this bug. ***
I tested Chris's fix and verified that it makes the OpenOffice.org crash go away. His fix is included in the recent cairo 1.4.10 release. New packages have been built for both F-7 and devel ("rawhide"), so should be appearing soon. I personally apologize for any lost data, and for the delay in getting a new package out to resolve this problem. But thanks to everyone running these bleeding-edge packages and reporting bugs! -Carl