Download it now!
Bug 125709 - FORMAT NUMBER DIALOG: Crash when changing language of date field
Summary: FORMAT NUMBER DIALOG: Crash when changing language of date field
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: KDE Fields-Dialog Crash
  Show dependency treegraph
 
Reported: 2019-06-05 12:15 UTC by Tóth Nikolett
Modified: 2020-11-13 04:08 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
The backtrace log (4.73 KB, text/x-log)
2019-06-06 08:32 UTC, Tóth Nikolett
Details
New backtrace log (4.21 KB, text/x-log)
2019-06-06 08:47 UTC, Tóth Nikolett
Details
gdb output and core dump (14.64 KB, text/x-log)
2019-06-06 09:25 UTC, Tóth Nikolett
Details
Valgrind log (4.49 KB, text/x-log)
2019-06-13 10:57 UTC, Tóth Nikolett
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tóth Nikolett 2019-06-05 12:15:00 UTC
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
Comment 1 Dieter 2019-06-05 12:28:02 UTC
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
Comment 2 Julien Nabet 2019-06-05 13:29:11 UTC
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 ?
Comment 3 Tóth Nikolett 2019-06-05 13:55:39 UTC
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.
Comment 4 Julien Nabet 2019-06-05 14:11:39 UTC
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.
Comment 5 Xisco Faulí 2019-06-05 14:46:33 UTC
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
Comment 6 Xisco Faulí 2019-06-05 14:47:41 UTC
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
Comment 7 Tóth Nikolett 2019-06-06 08:32:25 UTC
Created attachment 151954 [details]
The backtrace log
Comment 8 Tóth Nikolett 2019-06-06 08:33:02 UTC
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
Comment 9 Julien Nabet 2019-06-06 08:39:30 UTC
It's not a crash, you must type "c" (for "continue") until there's no "??"
Comment 10 Tóth Nikolett 2019-06-06 08:47:55 UTC
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.
Comment 11 Julien Nabet 2019-06-06 08:56:05 UTC
"/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.
Comment 12 Tóth Nikolett 2019-06-06 09:25:37 UTC
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.
Comment 13 Julien Nabet 2019-06-06 10:00:32 UTC
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.
Comment 14 Xisco Faulí 2019-06-06 11:03:58 UTC
(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
Comment 15 Tóth Nikolett 2019-06-06 12:54:12 UTC
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.
Comment 16 Julien Nabet 2019-06-06 13:09:32 UTC
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)?
Comment 17 Jan-Marek Glogowski 2019-06-13 01:04:53 UTC
(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.
Comment 18 Tóth Nikolett 2019-06-13 10:57:50 UTC
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.
Comment 19 Michael Weghorn 2019-06-14 07:39:55 UTC
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
Comment 20 Jan-Marek Glogowski 2019-06-14 11:27:35 UTC
(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".
Comment 21 QA Administrators 2019-12-14 03:41:22 UTC Comment hidden (obsolete)
Comment 22 opensuse.lietuviu.kalba 2020-01-05 20:46:31 UTC
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.
Comment 23 QA Administrators 2020-11-13 04:08:25 UTC
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