Bug 93978 - Crash after setting background to gradient (comment 9)
Summary: Crash after setting background to gradient (comment 9)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.0.1.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords: haveBacktrace, regression
: 94350 94352 96168 (view as bug list)
Depends on:
Blocks: RenderContext
  Show dependency treegraph
 
Reported: 2015-09-07 05:42 UTC by Yousuf Philips (jay) (retired)
Modified: 2015-12-01 10:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
backtrace (22.83 KB, text/plain)
2015-09-07 16:59 UTC, Yousuf Philips (jay) (retired)
Details
backtrace from pressing okay in page style dialog (31.72 KB, text/plain)
2015-09-20 07:17 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-09-07 05:42:01 UTC
Steps:
1) Open Writer
2) Format > Page
3) Set page background to gradient
4) Enable boders
5) Click on columns or footer tab and press OK button
6) Possible that it crashes here
7) Scroll mouse wheel while pressing ctrl to zoom
8) Possible crash here

This doesnt happen in 4.4.3 from what i can see.

@Maxim, @Meeks: Possible vclptr?

Version: 5.1.0.0.alpha1+
Build ID: cf9fbdb379e2935677a73ced513d7faf855c299c
TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2015-09-04_23:18:57
Locale: en-US (en_US.UTF-8)
Comment 1 Michael Meeks 2015-09-07 12:01:13 UTC
Interesting; I like the zooming in & out stuff ... is it possible that you have OpenGL enabled ? can you check your help->about - if the hash of the version has -GL at the end that is so.

I can't reproduce here sadly; thanks !
Comment 2 Yousuf Philips (jay) (retired) 2015-09-07 16:59:19 UTC
Created attachment 118503 [details]
backtrace

Silly me, i forgot to include the backtrace. :D

(In reply to Michael Meeks from comment #1)
> Interesting; I like the zooming in & out stuff ... is it possible that you
> have OpenGL enabled ? can you check your help->about - if the hash of the
> version has -GL at the end that is so.

No OpenGL isnt enabled. It was hard to reproduce as it would happen randomly and i couldnt find an exact set of steps to reproduce it everytime, but it did happen on two different computers.
Comment 3 Maxim Monastirsky 2015-09-07 17:43:48 UTC
(In reply to Yousuf (Jay) Philips from comment #2)
> Created attachment 118503 [details]
> backtrace
This one is similar to the stacks from Bug 91880 and Bug 92213.
Comment 4 Yousuf Philips (jay) (retired) 2015-09-08 05:26:48 UTC
(In reply to Maxim Monastirsky from comment #3)
> This one is similar to the stacks from Bug 91880 and Bug 92213.

So i guess the saga continues. Bug 92213 is RenderContext issue, so should this be set to block bug 91488?
Comment 5 Michael Meeks 2015-09-08 10:52:54 UTC
It could be related to RenderContext. It appears that (for some reason) - we're re-painting at a time when the window this VirtualDevice is being associated with has no screen (which is rather odd in itself) - perhaps it is not yet realized itself.

The critical bit is:

Program received signal SIGSEGV, Segmentation fault.
IA__gdk_x11_screen_get_screen_number (screen=0x0) at /build/buildd/gtk+2.0-2.24.23/gdk/x11/gdkscreen-x11.c:607
607	/build/buildd/gtk+2.0-2.24.23/gdk/x11/gdkscreen-x11.c: No such file or directory.
#0  IA__gdk_x11_screen_get_screen_number (screen=0x0) at /build/buildd/gtk+2.0-2.24.23/gdk/x11/gdkscreen-x11.c:607
#1  0x00007fffe17b9628 in GtkSalGraphics::GtkSalGraphics (this=0x1d98580, pFrame=0x0, pWindow=0x1ac73f0) at /home/buildslave/source/libo-core/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx:71
#2  0x00007fffe17a737e in GtkInstance::CreateVirtualDevice (this=0x61b6c0, pG=0x1be8e10, nDX=@0x7fffffffb9f8: 954, nDY=@0x7fffffffba00: 533, nBitCount=24, pGd=0x0) at /home/buildslave/source/libo-core/vcl/unx/gtk/app/gtkinst.cxx:333
#3  0x00007ffff0a30453 in VirtualDevice::InnerImplSetOutputSizePixel (this=0x1be8580, rNewSize=..., bErase=false, pBuffer=..., bTopDown=false) at /home/buildslave/source/libo-core/vcl/source/gdi/virdev.cxx:339
#4  0x00007ffff0a30836 in VirtualDevice::ImplSetOutputSizePixel (this=0x1be8580, rNewSize=..., bErase=false, pBuffer=..., bTopDown=false) at /home/buildslave/source/libo-core/vcl/source/gdi/virdev.cxx:396
#5  0x00007ffff0a30b91 in VirtualDevice::SetOutputSizePixel (this=0x1be8580, rNewSize=..., bErase=false) at /home/buildslave/source/libo-core/vcl/source/gdi/virdev.cxx:444
#6  0x00007fffec822e20 in (anonymous namespace)::VDevBuffer::alloc (this=0x1b59940, rOutDev=..., rSizePixel=..., bClear=false, nBits=24) at /home/buildslave/source/libo-core/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx:159
#7  0x00007fffec8238e6 in drawinglayer::impBufferDevice::impBufferDevice (this=0x7fffffffbf90, rOutDev=..., rRange=..., bAddOffsetToMapping=true) at /home/buildslave/source/libo-core/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx:254

I guess the mrOutDev passed to the buffer-device:

    impBufferDevice::impBufferDevice(
        OutputDevice& rOutDev,
        const basegfx::B2DRange& rRange,
        bool bAddOffsetToMapping)

is busted in some way.

Tomaz - can you have a look ? this may intersect with some problems we're seeing with GL rendering in the drawing-layer too.

Thanks for the help getting a trace; and it's unfortunate that it's not reproducible - I guess deep code-reading needed.
Comment 6 Yousuf Philips (jay) (retired) 2015-09-20 07:17:22 UTC
Created attachment 118868 [details]
backtrace from pressing okay in page style dialog

Was able to get it to crash from pressing OK in the page style dialog and will attempt to do it from a debug daily build.

Version: 5.1.0.0.alpha1+
Build ID: cbf3fac0a5a1be34b2e1a58da959debd24ebc017
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-17_07:03:22
Locale: en-US (en_US.UTF-8)
Comment 7 Maxim Monastirsky 2015-10-01 18:31:35 UTC
*** Bug 94350 has been marked as a duplicate of this bug. ***
Comment 8 Maxim Monastirsky 2015-10-01 18:32:06 UTC
*** Bug 94352 has been marked as a duplicate of this bug. ***
Comment 9 Maxim Monastirsky 2015-10-01 18:42:05 UTC
I found a reliable way of reproducing this crash. It seems to need slow hardware. I emulated it using a VirtualBox VM + playing with 'Execution Cap'. When 'Execution Cap' is at 100% the crash is never reproduced, but as soon as I use lower one (like 30% or 20%) it always crashes. Tested both 5.0 and master, with Ubuntu and Fedora VMs.

The easiest reproduction steps are from Bug 94352: Right click on a textbox, choose Area..., change to Gradient, and click OK.
Comment 10 Yousuf Philips (jay) (retired) 2015-10-02 15:41:16 UTC
(In reply to Maxim Monastirsky from comment #9)
> It seems to need slow hardware.

When you say slow hardware, do you mean old hardware. If so, i have opengl 1.4 on an Intel 945GM with 256 MB.

> The easiest reproduction steps are from Bug 94352: Right click on a textbox,
> choose Area..., change to Gradient, and click OK.

Not able to reproduce that. Are you sure you dont mean the simple steps in 94622.
Comment 11 Maxim Monastirsky 2015-10-03 22:18:25 UTC
(In reply to Yousuf (Jay) Philips from comment #10)
> When you say slow hardware, do you mean old hardware.
Mainly (but not limited to) slow CPU, because that's what the 'Execution Cap' trick emulates.

> Not able to reproduce that.
Those are the same steps you reported in Bug 92213, except that I used a gradient instead of a bitmap (both are crashing for me). Indeed, this one is tricky to reproduce, so it could be that not every repro steps are always crashing for everyone. What is clear is that all of them happen after you change the background type in the dialog and click OK, and all of them share the same backtrace.
Comment 12 Björn Michaelsen 2015-11-25 21:58:43 UTC
(In reply to Michael Meeks from comment #5)
> It could be related to RenderContext. It appears that (for some reason) -
> we're re-painting at a time when the window this VirtualDevice is being
> associated with has no screen (which is rather odd in itself) - perhaps it
> is not yet realized itself.
> 
> The critical bit is:
> (...)

Hah, I recognize that stacktrace! FWIW, this is the most common crash happening to LibreOffice right now according to errors.ubuntu.com and happened at least as early as 5.0.1. It did not happen on Ubuntu 15.04/LibreOffice 4.4.x, so indeed a regression.
Comment 13 Maxim Monastirsky 2015-11-28 20:41:06 UTC
@Caolán: I suppose this one is the same you fixed in:

commit 26c32cfee9fc9a769adba19f455e4d6c13b6d89d
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Fri Nov 27 16:10:10 2015 +0000

    Resolves: rhbz#1283426 using vdevs based on now dead physical devs is unsafe
    
    This is the same problem that
    
    commit 133e04fc1a870c0aad207e82eefeeeceaba5dc6d
    Author: Caolán McNamara <caolanm@redhat.com>
    Date:   Wed Jun 17 09:23:32 2015 +0100
    
        Resolves: tdf#91880 Invalidate graphics when the gtk window is destroyed
    
        not just when the GtkSalFrame is dtored
    
    tried to fix, but that just made it more unlikely to fail
    
    Change-Id: Icba750c787adb6cd5c5ed0874ef07e6201c4cf25
Comment 14 Caolán McNamara 2015-12-01 09:32:41 UTC
yes, that's the bug I'm trying to fix with that commit anyway.
Comment 15 Cor Nouws 2015-12-01 10:09:37 UTC
*** Bug 96168 has been marked as a duplicate of this bug. ***