On which Linux distrib are you? Could you upgrade to a recent LO version, 7.5.9 or last one 7.6.4 ? (by using distrib repo).
This issue happened with Xubuntu 22.04.3 LTS and LibreOffice Writer Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.4 Calc: threaded Yesterday LibreOffice repeatedly crashed when I pasted a screenshot from the clipboard into a small to medium sized document (ca 70 pages, my notebook). It also did not work through the Insert>Image way with it stored as a .png file. The notebook accumulates my experience during the upgrade from Xubuntu 20.04 to Xubuntu 22.04. Therefore it was made in many steps: re-opening, editing, pasting text and screenshots, storing. During the lifetime of it, one or two computer freezes happened, after which this particular document had to be reconstructed because LO Writer had be terminated "in an unusual way". LO Writer's reconstruction worked very well (loosing only a few last edits). Such crashes when pasting screenshot images from the clipboard or by Insert>Image happened to me before when editing much larger notebooks (with similar generation history, but 500 to 1000 pages long and encountering computer freezes too), but it wasn't usually as persistent as yesterday. After rebooting after a freeze, starting LO Writer offered to reconstruct all open documents due to irregularly terminating LO Wrtier too (albeit with small losses in the work in the last steps before the crash). When a LO Writer crash happens after pasting something, sometimes it helped to first copy/paste the additions (some 5 to 10 pages) into a new document and then copy and paste it to my notebook via the clipboard. But yesterday it failed several times consecutively but finally succeeded! However, there was no dialog asking whether the LO Writer crash should be reported to the developers. Today I saw a new 315 MB file /var/crash/_usr_lib_libreoffice_program_soffice.bin.1000.crash that was created yesterday. Most probably it has not been uploaded since there were no associated .upload oder .uploaded files around it. My notebook in question ist too big to be uploaded here and the file from /var/crash is particularly ill suited because of its tremendous size (probably it also contains information from the other 3 to 4 files open in LibreOffice at that time, one of them being a 1000 pages document of this kind from and after the last operating system upgrade. In the past I already had tried in vain to create a small example which reproducibly crashes when pasting ans image to some particular position in it. In yesterday's episode memory can not have been the reason, almost 1/4 of the available RAM was free (as seen from the cpu/memory/swap meter which I always have on the task bar: my first look in, after or around crash episodes ist that meter. **How should one proceed in such a case so that such errors do not remain under the radar?** **Is there some tool to check if an odt file adheres to the standards and if not: repairs it such that the repaired version become conformant? Or IS LO Writer itself already such a tool (by virtue of the reconstruction steps after an irregular termination of LO Writer?**
(In reply to Julien Nabet from comment #1) > On which Linux distrib are you? > > Could you upgrade to a recent LO version, 7.5.9 or last one 7.6.4 ? (by > using distrib repo). Sorry, by some error my bug report was sent before I had written down the details, therefore the midway collision. I'll install Version 7.6.4 subito and continue my work there. When the error shows up again, I'll report it here. Aside from the bug which may or may not have been corrected in 7.6.4, my question is about how to report crashes leaving traces in /var/crash but which did not go through a dialog "shall this bug be reported to the developers?".
To attach crash log, you can use the link https://bugs.documentfoundation.org/attachment.cgi?bugid=159590&action=enter (which allows to attach a file + comment). I forgot to tell to first give a try at https://bugs.documentfoundation.org/attachment.cgi?bugid=159590&action=enter. About upgrading, since you use Xubuntu you can use PPA repo (see https://launchpad.net/~libreoffice/+archive/ubuntu/ppa)
(In reply to Julien Nabet from comment #4) > To attach crash log, you can use the link > https://bugs.documentfoundation.org/attachment.cgi?bugid=159590&action=enter > (which allows to attach a file + comment). > > I forgot to tell to first give a try at > https://bugs.documentfoundation.org/attachment.cgi?bugid=159590&action=enter. > > About upgrading, since you use Xubuntu you can use PPA repo (see > https://launchpad.net/~libreoffice/+archive/ubuntu/ppa) Your last advice looks interesting to me: In general I have two LO versions in parallel: 1. the actual development one from https://dev-builds.libreoffice.org/daily/master/current.html (I install new ones about once a month or when I see, that something about which I have made a bug report has changed, whatever comes earlier) and 2. a more robust one, like Version: 7.6.4.1 (X86_64) or 7.3.7.2 before, which I have just replaced by the newer on according to your advice in Comment 1. Usually I work with the development version - unless I do work, where I can not afford an interruption by some software surprise. Just to make sure that I got it right: Would installing the PPA according to your last link supply me with regularly updated versions instead of version 7.6.4.1, which I have currently installed as a Debian package? Would testing, whether quirks from the development version show up in a more established version help better if that is the one from the PPA you mentioned?
(In reply to Adalbert Hanßen from comment #5) > ... > Just to make sure that I got it right: Would installing the PPA according to > your last link supply me with regularly updated versions instead of version > 7.6.4.1, which I have currently installed as a Debian package? Would > testing, whether quirks from the development version show up in a more > established version help better if that is the one from the PPA you > mentioned? I don't use Ubuntu, just Debian (the distrib from which Ubuntu is based) but I think PPA indeed delivers regularly updated versions. Quoting https://launchpad.net/~libreoffice/+archive/ubuntu/ppa "This PPA will have what the Document Foundation calls "LibreOffice fresh", the latest release of the newest series (but no alpha/beta releases)." => so no dev version from PPA. However, using packages from official LO website is ok for macOS and Windows but for Linux you must deal yourself dependencies pb if any. So the rpm and deb packages are more for Linux maintainers. You can also try master daily builds (see https://dev-builds.libreoffice.org/daily/master/), the directory with "dbg" means it'll provide extra debugging info but as for Linux package in LO website, you must have to deal with potential dependencies pbs.
Please let us know if you still experience the same issue with a currently supported version (7.6 or 24.2). Do you use Wayland? (you can check in Ubuntu's "About" dialog) Setting to "need info" for now. Thank you!
(In reply to Stéphane Guillou (stragu) from comment #7) > Please let us know if you still experience the same issue with a currently > supported version (7.6 or 24.2). > Do you use Wayland? (you can check in Ubuntu's "About" dialog) > Setting to "need info" for now. > Thank you! I did not experience the issue. But meanwhile I have uninstalled versions 7.6 and 24.2, currently I use Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8eee7eab8087590aa19bb9989c294e9be767f356 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded for my work. I am running a machine (only) with Xubuntu 22.04. I have not yet installed a stable LibreOffice fresh ppa as advised in comment 6. I don't know what you mean by Ubuntu's about dialog. Xubuntu is said to be somewhat in the middle of wayland and X11: $ echo $XDG_SESSION_TYPE x11 $ dpkg -l | grep wayland ii kwayland-data 4:5.92.0-0ubuntu1 all Qt library wrapper for Wayland libraries - data files ii kwayland-integration:amd64 4:5.24.4-0ubuntu1 amd64 kwayland runtime integration plugins ii libkf5waylandclient5:amd64 4:5.92.0-0ubuntu1 amd64 Qt library wrapper for Wayland libraries ii libqt5waylandclient5:amd64 5.15.3-1 amd64 QtWayland client library ii libqt5waylandcompositor5:amd64 5.15.3-1 amd64 QtWayland compositor library ii libva-wayland2:amd64 2.14.0-1 amd64 Video Acceleration (VA) API for Linux -- Wayland runtime ii libwayland-client0:amd64 1.20.0-1ubuntu0.1 amd64 wayland compositor infrastructure - client library ii libwayland-cursor0:amd64 1.20.0-1ubuntu0.1 amd64 wayland compositor infrastructure - cursor library ii libwayland-egl1:amd64 1.20.0-1ubuntu0.1 amd64 wayland compositor infrastructure - EGL library ii libwayland-server0:amd64 1.20.0-1ubuntu0.1 amd64 wayland compositor infrastructure - server library ii qtwayland5:amd64 5.15.3-1 amd64 QtWayland platform plugin $ I hope that this answers your questions.
Thanks for that. (In reply to Adalbert Hanßen from comment #8) > 7.6 and 24.2, currently I use > [24.8] > for my work. And have you been able to reproduce the crash in 24.8? The benefit of using the stable versions 7.6 or 24.2 would be more stability, as you know, but also easier crash reporting (if it is offered to you on restart of LO). If the crash dump in .config/libreoffice/4/crash is not too big, you can also attach that. If you find reliable steps to crash it, please let us know, possibly with a smaller document to start from. But hopefully, you just find that the issue is already resolved in 7.6/24.2/24.8.
(In reply to Stéphane Guillou (stragu) from comment #9) > Thanks for that. > (In reply to Adalbert Hanßen from comment #8) > > 7.6 and 24.2, currently I use > > [24.8] > > for my work. > And have you been able to reproduce the crash in 24.8? > The benefit of using the stable versions 7.6 or 24.2 would be more > stability, as you know, but also easier crash reporting (if it is offered to > you on restart of LO). I did not encounter this specific bug again when pasting a screenshot into my document, in which I record all my experiences with LO Writer, bug reports and so on. > If the crash dump in .config/libreoffice/4/crash is not too big, you can > also attach that. > If you find reliable steps to crash it, please let us know, possibly with a > smaller document to start from. > But hopefully, you just find that the issue is already resolved in > 7.6/24.2/24.8. The automatic mechanism after restart also happens with the development version. I think this is used as from the stable version - or is there a difference? Of course I encountered a few crashes and I let the bug reports be uploaded by the automatic mechanism after restart. Fortunately not much work was lost. Unfortunately the automatic reporting mechanism does not ask for a comment about what one did before the crash happened. In many cases, I can't exactly remember it but in some of them I do. I guess, sometimes such additional information might be helpful for bug fixing. The crashes with the development version of 2024-02-24 were so frequent that I updated it gin on 2024-02-26. There still is a crash report /var/crash/_opt_libreofficedev24.8_program_soffice.bin.1000.crash, but it is 465MB big! Crashes happen more frequent with a development version than with a stable one. In general I only update the development version about twice per month. But if it crashes too often, I update earlier. Hopefully this will help fixing bugs and improving LO, but limit my extra effort to some affordable level.
I have just looked at .config/libreoffice/4/crash: There were a few dumps, each ca 700k big. But they all were from last year. Therefore I have deleted them. I'll look at this place in other accounts too.
(In reply to Adalbert Hanßen from comment #10) > (In reply to Stéphane Guillou (stragu) from comment #9) > > Thanks for that. > > (In reply to Adalbert Hanßen from comment #8) > > > 7.6 and 24.2, currently I use > > > [24.8] > > > for my work. > > And have you been able to reproduce the crash in 24.8? > > The benefit of using the stable versions 7.6 or 24.2 would be more > > stability, as you know, but also easier crash reporting (if it is offered to > > you on restart of LO). > > I did not encounter this specific bug again when pasting a screenshot into > my document, in which I record all my experiences with LO Writer, bug > reports and so on. That's good news, let's mark this specific issue as "works for me" then (as it is the focus of this report). > The automatic mechanism after restart also happens with the development > version. I think this is used as from the stable version - or is there a > difference? The dialog pops up also for dev versions, but unfortunately it does not send the crash report. > Unfortunately the automatic reporting mechanism does not ask for a > comment about what one did before the crash happened. In many cases, I can't > exactly remember it but in some of them I do. I guess, sometimes such > additional information might be helpful for bug fixing. With a release version (not a dev version), there should be the link to the crash report in the dialog (something like https://crashreport.libreoffice.org/stats/crash_details followed by a long string). You can follow that link, and then click the link after "File a bug for". That will open a new bug report linked to that crash report. > Crashes happen more frequent with a development version than with a stable > one. Yes, and I would recommend sticking to the current "stable" versions for your work, 7.6 or 24.2. You can keep your dev build installed alongside to help with quality assurance. > Hopefully this will help fixing bugs and improving LO, but limit my extra > effort to some affordable level. Your help is very much appreciated! :)
(In reply to Stéphane Guillou (stragu) from comment #12) > ... > > The automatic mechanism after restart also happens with the development > > version. I think this is used as from the stable version - or is there a > > difference? > The dialog pops up also for dev versions, but unfortunately it does not send > the crash report. > > Unfortunately the automatic reporting mechanism does not ask for a > > comment about what one did before the crash happened. In many cases, I can't > > exactly remember it but in some of them I do. I guess, sometimes such > > additional information might be helpful for bug fixing. That is a pity. Because you definitely need error messages from development versions, an automated feedback channel should also be effective. > With a release version (not a dev version), there should be the link to the > crash report in the dialog (something like > https://crashreport.libreoffice.org/stats/crash_details followed by a long > string). You can follow that link, and then click the link after "File a bug > for". That will open a new bug report linked to that crash report. I'll keep that in mind. I have looked through .config/libreoffice/4/crash on the other user's account but did not find a local crash report from that date there. The only one still present on my machine is that /var/crash/_opt_libreofficedev24.8_program_soffice.bin.1000.crash. The first few lines of that are $ cat /var/crash/_opt_libreofficedev24.8_program_soffice.bin.1000.crash | head -n 1000 ProblemType: Crash Architecture: amd64 CurrentDesktop: XFCE Date: Sun Feb 25 22:32:20 2024 DistroRelease: Ubuntu 22.04 ExecutablePath: /opt/libreofficedev24.8/program/soffice.bin ExecutableTimestamp: 1708742559 ProcCmdline: /opt/libreofficedev24.8/program/soffice.bin --writer file:///home/verwalter/Schreibtisch/_Xubuntu%2022.04%20auf%20W530-SSD.odt --splash-pipe=5 ProcCwd: /home/verwalter/Schreibtisch ProcEnviron: LANGUAGE=de_DE PATH=(custom, user) XDG_RUNTIME_DIR=<set> LD_PRELOAD=<set> LANG=de_DE.UTF-8 SHELL=/bin/bash LD_LIBRARY_PATH=<set> ProcMaps: 00400000-00401000 r--p 00000000 08:07 2266847 /opt/libreofficedev24.8/program/soffice.bin 00401000-00402000 r-xp 00001000 08:07 2266847 /opt/libreofficedev24.8/program/soffice.bin 00402000-00403000 r--p 00002000 08:07 2266847 /opt/libreofficedev24.8/program/soffice.bin 00403000-00404000 r--p 00002000 08:07 2266847 /opt/libreofficedev24.8/program/soffice.bin 00404000-00405000 rw-p 00003000 08:07 2266847 /opt/libreofficedev24.8/program/soffice.bin 00911000-173ec000 rw-p 00000000 00:00 0 [heap] ... If you are really interested in that crash report, please tell me how to send you this quite big file. Fortunately the issue has not re-appeared with the development versions used after this one, so probably you won't need that one any more. When I encounter the next crash, I'll look for crash dumps in ~/.config/libreoffice/4/crash.
Created attachment 193013 [details] Crash reoport generated by LO Impress developer version (In reply to Stéphane Guillou (stragu) from comment #12) > (In reply to Adalbert Hanßen from comment #10) > > (In reply to Stéphane Guillou (stragu) from comment #9) ... > The dialog pops up also for dev versions, but unfortunately it does not send > the crash report. ... Today I encountered a crash with LO Impress Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d2fa44db6f8a1badece63856ee0f12db4cba9b28 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded There was no local file in ~/.config/libreoffice/4/crash from today. The only file there is dump.ini: ProductName=LibreOffice Version=24.2.0.3 BuildID=da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 URL=https://crashreport.libreoffice.org/submit/ Language=de-DE CPUModelName=Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz CPUFlags=fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d MemoryTotal=6790796 kB UseSkia=false ShutDown=true is that right or is its content wrong and prevents generating a short crash report there? After the crash it went through the normal error reporting mechanism like in the released version (which you told me that it does not work for the development version). I found /var/crash/_usr_lib_x86_64-linux-gnu_tumbler-1_tumblerd.1001.crash. Therefore attach the first 1025 lines before the core dump from that file.
We rather need a backtrace here. (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU/Linux:_How_to_get_a_backtrace)
(In reply to Julien Nabet from comment #15) > We rather need a backtrace here. (see > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU/Linux: > _How_to_get_a_backtrace) As this issue just happened one single time and I don't remember exactly the steps I did before the crash happened: Did I understand it right: Prerequisite for making such a backtrace is that I can cause this bug to happen reproducibly. If this is the case, it is worth following the steps in your linked article and hope that the same bug also shows up also when calling in the backtrace mode soffice --backtrace and do the other steps before and after it as in your linked articles. Right? (Fortunately the bug was not so nasty to show up over and over again, so right now it is not the time for it). In the case of the development version (see above), will I have to call soffice, or will it be a varied name specifying the development version? If this is the case: what is the exact name to be called with --backtrace?
(In reply to Adalbert Hanßen from comment #14) > After the crash it went through the normal error reporting mechanism like in > the released version (which you told me that it does not work for the > development version). What I meant is that there isn't a dialog that offers you to directly send a crash report. If you stick to a release version (e.g. 24.2), that dialog should be there to make it easy to send a report after a crash. Probably a good idea to stick to a stable release for this reason. (In reply to Adalbert Hanßen from comment #16) > In the case of the development version (see above), will I have to call > soffice, or will it be a varied name specifying the development version? If > this is the case: what is the exact name to be called with --backtrace? As explained in the wiki, you would have to start LO with the command: soffice --backtrace ... but making sure that soffice is from the debug build you downloaded and extracted. So likely something like: <wherever_you_extracted>/instdir/program/soffice --backtrace