This is Windows bug for ODP attachment 165738 [details] from Linux bug 136933. There's crash in Windows with 7.1+ Skia, no crash with LO 7.0 beta Skia. Buovjaga confirmed crashes on Win with Skia/Raster. Telesto wrote: not a crash, only lots of CPU time being wasted. Time in Skia Raster seems to be spend in: rtl_math_approxEqual basegfx::utils::isPointOnLine basegfx::utils::isPointOnPolygon Very slow with Skia. Faster and no crash with GDI, just flickering, which is likely Fade Smoothly transition bug 91456.
I'm not sure about "no crash with LO 7.0 beta Skia", next time there is, so I don't mark regression, probably it's not.
With fixing the slowness in bug 136933, I cannot reproduce any more problems. Please provide more information about the crash.
No crashing anymore with Version: 7.1.0.0.alpha0+ Build ID: 614d310751d1a32baec85c11637fb3813a9dd749 CPU threads: 8; OS: Linux 5.8; UI render: Skia/Vulkan; VCL: x11 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
No crash in: Version: 7.1.0.0.alpha0+ (x64) Build ID: f266feaebea39668392e3a3830e20e4670344658 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: bs-BA (bs_BA); UI: en-US I non-consistently reproduce crash (i.e. after a few runs) in Linux GTK3 (Mint 19 as VM) for GDI, not Skia. Version: 7.1.0.0.alpha0+ Build ID: 6923b1d527fa86fac8439b881d4ad468b765e915 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Before last change, I created attachment 165830 [details] gdbtrace.log. With SAL_USE_VCLPLUGIN=gen or SAL_ENABLESKIA=1 SAL_USE_VCLPLUGIN=gen it doesn't crash for me. We can change this bug from Skia to Linux GDI or open a new bug.
Seemed to me that LO 6.0 oldest was good in Linux and 6.0 master wrong. But this is not always reproducible, so 1st bibisect was wrong. commit 407e6633be2238b56a3273d62556f6a094cc139c source e0aed1459513be5e08fab9de06848df5dc9d0b5f previous source e159f8b128a9fd1eda8e499e12304aaef97bd7e0 2nd try seems correct (I set automatic slide transition after 1 sec): commit b0ce0483e059198d2ffb453fb6a55741627b7a1c Date: Thu Sep 21 08:51:13 2017 +0200 source 551ba337aa22b091f99ac91bf48543dc44ea981f previous source 7480094c3e71ff0538734eb360ab5f9ed2b66243 author Noel Grandin <noel.grandin@collabora.co.uk> 2017-09-19 10:37:06 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2017-09-19 15:04:03 +0200 commit 551ba337aa22b091f99ac91bf48543dc44ea981f (patch) tree a207fad4a209ef39d8414474f83e546c0b9c9a78 parent 7480094c3e71ff0538734eb360ab5f9ed2b66243 (diff) rename GtkData to GtkSalData to match all of the other SalData derivates Change-Id: I1d40ea5934edbeab747c10570657ac7d23230840 Reviewed-on: https://gerrit.libreoffice.org/42454 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Noel, please take a look. I can still repro in 7.1+ in Linux GTK3, it's VM with Mint 19.
That commit seems very unlikely to have caused a problem, since it's just a straight rename. Anyhow, I don't currently have a Linux setup I can debug on, thanks to the Wayland people repeatedly borking my remote desktop access.
Buovjaga and Xisco, please test, to be sure if this is for all GDI or just some. I repeatedly reproduce with this commit and not with previous one.
Created attachment 166152 [details] Backtrace of crash I repro the crash only with gtk3 Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: a16f2d2bc1865dfbf8e755e683624843337c59da CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 7 October 2020 (In reply to Timur from comment #7) > Buovjaga and Xisco, please test, to be sure if this is for all GDI or just > some. > I repeatedly reproduce with this commit and not with previous one. GDI is for Windows btw.: https://en.wikipedia.org/wiki/Graphics_Device_Interface
In Linux bibisect repo 7.0, the crash changed from happening after the first slide to happening after the last slide. However, the crash after the last slide is not always reproduced, so this was confusing at first. The crash after first slide seemed to be consistent, so I bisected using it as a guideline. I got this range: https://git.libreoffice.org/core/+log/f22044a49a56e585e2e9f419a1b77aba263b2afe/ f22044a Fix mid-air collision by Stephan Bergmann · 10 months ago 117963a Update git submodules by LibreOfficiant · 10 months ago ac793c7 tdf#129188 drawinglayer: implement EMF+ SetTextContrast by Chris Sherlock · 10 months ago 0c764bf add a SystemChildWindow::GetOptimalSize override by Caolán McNamara · 10 months ago b37540b remove can-focus when focus is lost by Caolán McNamara · 10 months ago a3f2c64 handle change of focus between widgets within the toplevel GtkWindow by Caolán McNamara · 10 months ago 85c10c4 Fix typo in code by Andrea Gelmini · 10 months ago bce3b6a allow default GtkWindow to handle key events first by Caolán McNamara · 10 months ago 27b6c82 tdf#129247 writerfilter,sw: improve handling of CONTROL fields by Michael Stahl · 10 months ago
A crash in /usr/lib/dri/iris_dri.so is a crash in mesa-dri-drivers (well that's the fedora package) You'd need to get the debug packages for that installed to get a backtrace that shows what function in that is actually crashing. It all works fine for me under wayland or X on my Fedora 32 install. Is this real hardware or under a vm ?
(In reply to Caolán McNamara from comment #10) > A crash in /usr/lib/dri/iris_dri.so is a crash in mesa-dri-drivers (well > that's the fedora package) You'd need to get the debug packages for that > installed to get a backtrace that shows what function in that is actually > crashing. It all works fine for me under wayland or X on my Fedora 32 > install. > > Is this real hardware or under a vm ? Damn. Real hardware for myself. Sadly Arch Linux doesn't ship debug packages. Timur might use Ubuntu's debug packages, if the crash is the same for him.
Created attachment 166158 [details] Backtrace of crash in Ubuntu VM with libgl1-mesa-dev Mine is VM. dpkg -l | grep mesa libegl-mesa0:amd64 free implementation of the EGL API -- Mesa vendor library libegl-mesa0:i386 free implementation of the EGL API -- Mesa vendor library libegl1-mesa:amd64 transitional dummy package libgl1-mesa-dri:amd64 free implementation of the OpenGL API -- DRI modules libgl1-mesa-dri:i386 free implementation of the OpenGL API -- DRI modules libgl1-mesa-glx:amd64 transitional dummy package libgl1-mesa-glx:i386 transitional dummy package libglapi-mesa:amd64 free implementation of the GL API -- shared library libglapi-mesa:i386 free implementation of the GL API -- shared library libgles2-mesa:amd64 transitional dummy package libglu1-mesa:amd64 Mesa OpenGL utility library (GLU) libglu1-mesa:i386 Mesa OpenGL utility library (GLU) libglx-mesa0:amd64 free implement. of the OpenGL API -- GLX vendor library libglx-mesa0:i386 free implement. of the OpenGL API -- GLX vendor library libosmesa6:amd64 Mesa Off-screen rendering extension libosmesa6:i386 Mesa Off-screen rendering extension libwayland-egl1-mesa:amd64 transitional dummy package libwayland-egl1-mesa:i386 transitional dummy package mesa-utils Miscellaneous Mesa GL utilities mesa-va-drivers:amd64 Mesa VA-API video acceleration drivers I assumed that DRI is important and debug is libgl1-mesa-dev, so installed. Here is gdbtrace.
Caolán, I'm not sure if you are following this so I add you. Thanks.
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so is also mesa-dri-drivers but there are no symbols so what function is crashing is unknown its possible that export LIBGL_DEBUG=verbose might give some extra info Using gtk3-demo and its "opengl area" demo to see if that's crash free is worth checking. glxgears too I guess. You may get a better result reporting this to your distro
Doesn't happen under Wayland for what it's worth. Timur: I guess we should close this as notourbug.
Created attachment 166513 [details] Backtrace of crash with LIBGL_DEBUG When I run "opengl area" it first starts but then turns to black rectangle. I also reproduced this in new Ubuntu 20.04. Here is gdbtrace.log with export LIBGL_DEBUG=verbose Feel free to close.
yeah, sounds like something to try the distro about to see if the root problem can be identified.