Created attachment 176334 [details] output: clinfo With fractional scaling ooimpress crashes immediately after entering presentation mode. [code]*** stack smashing detected ***: terminated[/code] this can be avoided, by disable the fricunal scaling multiplier and set it so 100% or 200%. Than everything works as expected.
On which env are you? (Linux, Windows, MacOs) If Linux, which distrib? Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ? Do you reproduce this with a presentation containing just 2 slides with "test"?
(In reply to Julien Nabet from comment #1) > On which env are you? (Linux, Windows, MacOs) > If Linux, which distrib? > Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ? > Do you reproduce this with a presentation containing just 2 slides with > "test"? Crashes also occur with two pages and a fresh user profile and disabled extensions. However, meanwhile figured out that it only occurs at 125% fractional scaling. everything else (150%,175% etc) works like expected. Fedora 35 DE: Gnome 41 Xwayland: 21.1.3 clinfo already attached. anything else?
I saw your attachment but I don't know this kind of file. Since it's OpenCL, did you try specifically https://wiki.documentfoundation.org/QA/FirstSteps#Computation-related_issues_in_Calc_.28OpenCL.29 ? If it's not OpenCL related, to know if it's gtk related, could you try this: - open a term/console - export SAL_USE_VCLPLUGIN=gen && soffice --impress - try to reproduce the pb In all cases, it could be useful to retrieve a backtrace (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
Created attachment 176356 [details] gdbtrace gdbtrace.log
Hi, thanks for sharing the instructuions. export SAL_USE_VCLPLUGIN=gen && soffice --impress and -- backtrace works without crash. Therefore GTK related if understood correctly. gdbtrace.log attached.
Let's try another way to retrieve a backtrace because the gdbtrace is not clear (at least for me). Could you try this: 1) open a first term/console and launch LO 2) open a second term/console and do: 2a) gdb --pid=$(pidof soffice.bin) 2b) c 3) go back to first term and reproduce the pb 4) go to second term and you'll see some segfault 5) type "bt" to retrieve the backtrace
(gdb) c Continuing. Thread 1 "soffice.bin" received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 Downloading 0.00 MB source file /usr/src/debug/glibc-2.34-9.fc35.x86_64/nptl/pthread_kill.c 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007fdd6c8208c3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007fdd6c7d36b6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fdd6c7bd7d3 in __GI_abort () at abort.c:79 #4 0x00007fdd6c814a27 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fdd6c951446 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #5 0x00007fdd6c8b21fa in __GI___fortify_fail ( msg=msg@entry=0x7fdd6c95142e "stack smashing detected") at fortify_fail.c:26 #6 0x00007fdd6c8b21c6 in __stack_chk_fail () at stack_chk_fail.c:24 #7 0x00007fdd65715ed8 in composite_boxes (compositor=<optimized out>, extents=0x7ffedc8c4c50, boxes=<optimized out>) at /usr/src/debug/cairo-1.17.4-4.fc35.x86_64/src/cairo-spans-compositor.c:747 #8 0x00eff7f7f7f7f7f7 in ?? () #9 0x00007fdd6c98baa0 in ?? () from /lib64/libc.so.6 #10 0x0000000000000000 in ?? () (gdb)
I don't know how to interpret the trace :-( I tried to reproduce the pb by following these steps: - create a brand new file - Type test on first slide - Duplicate slide - Save in /tmp/test.odp - Double click at bottom right to show the "Zoom & View Layout" window - Select Variable and put 125% - OK - Click F5 => no crash Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: 187b28063fa9b908f5324ed345ba223d8f6168a2 CPU threads: 12; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded lib gtk3 3.24 GLIBC 2.32-4 libcairo2 1.16.0-5
This looks the same as https://gitlab.freedesktop.org/cairo/cairo/-/issues/437 which was an issue in cairo with just the type of scenario described by the reporter here