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 !

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.

(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.

(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?

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.

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)

*** Bug 94350 has been marked as a duplicate of this bug. ***

*** Bug 94352 has been marked as a duplicate of this bug. ***

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.

(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.

(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.

(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.

@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

yes, that's the bug I'm trying to fix with that commit anyway.

*** Bug 96168 has been marked as a duplicate of this bug. ***