Description: In LibreOffice Writer, I inserted a date field (not the fixed one). Sometimes it even crashes when I click "Additional formats...", but it's doesn't happen all the time. What happens all the time though, is that when I try to change the language of the field, and actually select the needed language, LibreOffice crashes. Steps to Reproduce: 1. Insert a Date field 2. Double click on the inserted field to edit it 3. Click on "Additional formats..." 4. Try to change the language of the field. Actual Results: LibreOffice crashes. Expected Results: Change the language of the field after clicking "Ok". Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Can't confirm it with Version: 6.2.4.2 (x64) Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
On Win10 + LO 6.2.4, I don't reproduce this. Perhaps Linux only bug. Meanwhile, could you give a try to https://wiki.documentfoundation.org/QA/FirstSteps ?
I gave it a try, unfortunately the problem still remains on my computer. I used the latest LibreOffice (6.2.4), tried to change the date field's language to hungarian with the steps I wrote in the bug report, but it still crashed in safe mode too, so if the wiki is right, it's not a problem that's caused by the user profile. The UI Render is set to default, so most probably it isn't OpenGL what's causing the problem (according to the wiki page you linked), and the "Allow use of OpenCL" was unchecked the whole time (or, at least, it wasn't checked when I reached this part of the page and wanted to try reproducing the bug). I don't know if it's related or helps, but I'm using Arch Linux with the 5.1.5 kernel.
Thank you for your feedback. Would it be possible you retrieve a backtrace (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)? Indeed, it could provide some hints about root cause.
I can't reproduce it in Versión: 6.2.4.2 Id. de compilación: 2412653d852ce75f65fbfa83fb7e7b669a126d64 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
Nor in Version: 6.4.0.0.alpha0+ Build ID: 569b77647e8852899e65e660166b2d97b1c15d28 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Tóth Nikolett, Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
Created attachment 151954 [details] The backtrace log
Sorry for the late reply. I tried to retrieve the backtrace, but what's really odd, that I didn't even manage to create a writer document in debug mode. I tried it a few times, but it always crashed when I tried to create a new document. I attached the log anyway, I hope it can provide some useful information. The info from Help - about LibreOffice: Version: 6.2.4.2.0+ Build ID: 6.2.4-1 CPU threads: 4; OS: Linux 5.1; UI render: default; VCL: kde5; Locale: hu-HU (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
It's not a crash, you must type "c" (for "continue") until there's no "??"
Created attachment 151957 [details] New backtrace log Oh, sorry, and thanks for helping! I reproduced the bug in debug mode, and attached the retrieved log.
"/usr/lib/libreoffice/program/gdbtrace:9: Error in sourced command file: No stack. Thread 1 "soffice.bin" received signal SIGABRT, Aborted. 0x00007ffff7ce782f in raise () from /usr/lib/libc.so.6 Continuing." so no useful info here. Here's another way to retrieve a backtrace: 1) launch LO from a console 2) from another console, type this: gdb --pid=$(pidof soffice.bin) then "c" to continue. 3) Reproduce the crash 4) Type "c" when you got "??" until you've got something else. Hope, you'll get something.
Created attachment 151959 [details] gdb output and core dump I tried to debug it this way. In the file I attached, the first part contains the output of gdb while debugging, and the second part is the core dump I retrieved with journalctl. I couldn't really retrieve anymore with gdb, at least `(gdb) backtrace` didn't really provide anything.
This part is interesting: Stack trace of thread 26953: #0 0x00007eff273f7e54 _ZNK12QCommonStyle14subControlRectEN6QStyle14ComplexControlEPK19QStyleOptionComplexNS0_10SubControlEPK7QWidget (libQt5Widgets.so.5) #1 0x00007eff1ebae18f n/a (breeze.so) #2 0x00007eff2740a1ac _ZNK12QCommonStyle18drawComplexControlEN6QStyle14ComplexControlEPK19QStyleOptionComplexP8QPainterPK7QWidget (libQt5Widgets.so.5) #3 0x00007eff1ebaff72 n/a (breeze.so) #4 0x00007eff1ebafb75 n/a (breeze.so) #5 0x00007eff271edc07 n/a (libvclplug_qt5lo.so) #6 0x00007eff271ef0e9 _ZN20Qt5Graphics_Controls17drawNativeControlE11ControlType11ControlPartRKN5tools9RectangleE12ControlStateRK16ImplControlValueRKN3rtl8OUStringE (libvclplug_qt5lo.so) #7 0x00007eff3206b818 n/a (libvclplug_kde5lo.so) #8 0x00007eff2eb43cc5 _ZN11SalGraphics17DrawNativeControlE11ControlType11ControlPartRKN5tools9RectangleE12ControlStateRK16ImplControlValueRKN3rtl8OUStringEPK12OutputDevice (libvcllo.so) #9 0x00007eff2ea19b94 _ZN12OutputDevice17DrawNativeControlE11ControlType11ControlPartRKN5tools9RectangleE12ControlStateRK16ImplControlValueRKN3rtl8OUStringE (libvcllo.so) Could you give a try with another rendering than kde5? (eg: "gen" rendering) Let's put this one to NEW since there's a bt.
(In reply to Julien Nabet from comment #13) > Could you give a try with another rendering than kde5? (eg: "gen" rendering) You can do it by launching LibreOffice from commandline with SAL_USE_VCLPLUGIN=gen <path to soffice>/soffice
I gave it a try with another rendering (gen, as you advised), now it doesn't produce a core dump, but still gets an abort signal nevertheless when trying to double click on "Additional formats...". So I tried then with qt5, which does the same as gen: no core dump, but the abort signal remains.
Quite weird there's no bt. Another thing I noticed in the last bt retrieved is "Breeze". Just for the test, could you try to reproduce this with another UI theme (options/tools/display, icon style)?
(In reply to Julien Nabet from comment #16) > Another thing I noticed in the last bt retrieved is "Breeze". > > Just for the test, could you try to reproduce this with another UI theme > (options/tools/display, icon style)? The breeze.so is the Qt style - that is independent from the icon set in use by LO. You could check if setting an other style in KDE fixes the crash, but I doubt it. Currently I suspect either a Qt or KDE bug or generally a memory corruption. Would be interesting to know if master also fails: https://dev-builds.libreoffice.org/daily/ More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Or install valgrind and set "export VALGRIND=memcheck" and start soffice (will be very slow) and attach the logs.
Created attachment 152166 [details] Valgrind log Okay, so, I gave it a try at first with another rendering than kde5, unfortunately with no success at all, not with gen and neither with qt5. I couldn't yet try the master branch, but will definitely give it a try. I ran it with valgrind though, and attached the log. What I exactly did is that I started the program with `valgrind --leak-check=yes soffice 2> valgrind_log_soffice.log`, created a new document, added a date field, double clicked on it, then tried to click on "Additional formats...". It crashed, but even though it restarted, valgrind now didn't exit before the recovery dialog. So I recovered the document, tried double clicking on the field, then "Additional formats...", only to see it crash again. I did the recovery process, then exited soffice, and with that, valgrind exited too.
I can't reproduce with the same version (or master) on Debian testing (plasma-workspace 4:5.14.5.1-1, breeze 4:5.14.5-1, libqt5core5a:amd64 5.11.3+dfsg1-1) with Plasma (X11) and the Breeze theme: Version: 6.2.4.2 Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Tóth Nikolett from comment #18) > Created attachment 152166 [details] > Valgrind log > > Okay, so, I gave it a try at first with another rendering than kde5, > unfortunately with no success at all, not with gen and neither with qt5. > > I couldn't yet try the master branch, but will definitely give it a try. > > I ran it with valgrind though, and attached the log. What I exactly did is > that I started the program with `valgrind --leak-check=yes soffice 2> > valgrind_log_soffice.log`, created a new document, added a date field, > double clicked on it, then tried to click on "Additional formats...". It > crashed, but even though it restarted, valgrind now didn't exit before the > recovery dialog. So I recovered the document, tried double clicking on the > field, then "Additional formats...", only to see it crash again. I did the > recovery process, then exited soffice, and with that, valgrind exited too. Yup. Because you valgrind'ed bash (see your log: /usr/bin/bash :-). soffice is a script, run by bash. The script will evaluate VALGRIND=memcheck and start valgrind correctly with soffice.bin, the "real" LO. So please use an export or run "VALGRIND=memcheck soffice".
Dear Tóth Nikolett, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
I can not reproduce in LibreOffice 6.3.4.2 with kde5 backend in openSUSE Leap 15.1 with KDE Plasma 5.12.8 + Qt 5.9.7 + KF 5.55, Fusion and Breeze styles tested.
Dear Tóth Nikolett, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp