Steps to reproduce: - open the attached .odp file in Impress - run the macro named pavage_etoiles => CRASH Tested on Debian 11 Bullseye (with wayland) with LO-7.0.1.2
There is no CRASH when using LO-6.4.6.
There's no attached odp here.
Created attachment 166065 [details] .odp file to reproduce the problem Sorry, my mistake. Here it is.
I gave a try but the macro stops on line 29 with popup: "Basic runtime error. Sub-procedure or function procedure not defined". (I don't have Rotation function)
Created attachment 166082 [details] .odp file to reproduce the problem Sorry, my mistake again. Here is an updated .odp file. Hopefully this time it is complete.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. Now, I'm not sure if LO uses Wayland or not for me.
I tested the AppImages of fresh (7.0.x) and master (7.1.x). I can the crash only with the fresh, not with master. So this really seems to be fresh specific.
I can't reproduce it in Version: 7.0.2.0.0+ Build ID: b27137a7091104cce177791478e86d127680c9af CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: tr-TR (en_US.UTF-8); UI: en-US Calc: threaded
I can reproduce using: Version: 7.0.2.2 Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
Frédéric: would it be possible you retrieve a stacktrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
I did not manage to get a stacktrace, but when I run soffice from the command line, I get the following error message: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. Gdk-Message: 11:49:51.313: Lost connection to Wayland compositor. When I try to get a backtrace, I get: $ soffice --backtrace GNU gdb (Debian 9.2-1) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/libreoffice/program/soffice.bin... (No debugging symbols found in /usr/lib/libreoffice/program/soffice.bin) log will be saved as gdbtrace.log, this will take some time, patience... [Detaching after fork from child process 98807] And neither gdb nor LibreOffice starts.
I must recognize I'm stuck. I can't help here=>uncc myself.
Created attachment 166305 [details] backtrace Today I made an apt upgrade of my bullseye system and I can now open soffice in debug mode. I attach the backtrace log. However, when in debug mode, LO crashes before, just when opening the file.
Tonight, I checked with X instead of wayland and the problem does not show up. So this really seems to be wayland related, as the output from the command line was indicating.
(In reply to Frederic Parrenin from comment #13) > Created attachment 166305 [details] > backtrace > > Today I made an apt upgrade of my bullseye system and I can now open soffice > in debug mode. > I attach the backtrace log. > However, when in debug mode, LO crashes before, just when opening the file. The SIGSEGV in the backtrace is inside the JRE, which uses SIGSEGV for "normal operation" for communication, so that's most probably unrelated. Do you have any Java extensions installed? If those are note relevant to the actual problem, I'd recommend removing them, or even better, try with a fresh LibreOffice profile after all.
I can reproduce this if, while the macro is busy, I click on libreoffice a bunch of times, though I feel the fundamental problem is not ours.
If I disable setting the clipboard then I don't get a crash so maybe there's a route to avoiding this problem
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e2f66f5ba5d813af97bc4fb5f28cea9d737e25e9 Related: tdf#137181 factor out the piece that triggers the problem It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2194e2dd7e54ad6babec26cf05226b35d34cd309 Resolves: tdf#137181 set the clipboard asynchronously It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/057be6fd40fa32426a747f032b867be145797c6b Resolves: tdf#137181 set the clipboard asynchronously It will be available in 7.0.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
If we avoid hammering clipboard updates and just schedule one clipboard update to happen on the next event loop I don't get the crash anyone.