Created attachment 178959 [details] bug report with screenshots. The bug report process should also be improved! This bug report pertains to LibreOffice Writer Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 778bbcede813dd51e11ee61583247db1199eda63 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded For certain large documents I a currently working on, the whereas LibreOfficeWriter Version: 6.4.4.2 Build-ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU-Threads: 4; BS: Linux 5.4; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded has no problem opening the same files.
As for me, I would have expected an example file attached, sanitized if needed (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission) to try to reproduce this. Also, you mix 2 issues: - crash when opening specific big files - enhancement about reporting bugs I would have expected 1 issue per bugtracker, above all if both are independent.
Please attach your problem file here
(In reply to Roman Kuznetsov from comment #2) > Please attach your problem file here Unfortunately I can not publish the file in question because of their content. I tried to replace all characters in the smallest one of them (9 MB) by a capital A in LibreOffice 6.3, which definitely made the content unreadable, but after this manipulation the document did not show the crash behaviour any longer. The 9MB file still would exceed the size limit of this forum. But the crash behaviour still appeared after updating my Linux kernel to 5.4.0-105-generic x86_64. In the meantime I had upgraded to a slightly newer Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 59a7c40255b836ed75e64686fabb3e9938b755f0 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded but this one also shows the bug un those files where they appeared before. By the way: The bug tracking mechanism should be improved to let the user give additional information and tell him a reference token in order to communicate about crashes which they have experienced.
[Automated Action] NeedInfo-To-Unconfirmed
We can't find the problem without file example anyway. I you will can create some example without confidential data please attach it here Status NEEDINFO while we will wait the example for repro. Thanks
Created attachment 179320 [details] File which reproducibly causes a crash Fortunately ;-) now I stumbled over a *small* example of what drives me crazy: LO Writer' Development version crashes with many files im am working on, but most of them are large ones. I see myself using version 6.4.4.2 more frequently than before! Here is a modestly sized example, but it is still several pages long. I tried to make it even shorter, but I did not succeed with that attempt. This file can be viewed and processed with LibreOfficeWriter Version 6.4.4.2. === The crash happens if the appended file is opened with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2816f498505bab01bc0f17ef0962ece663c607c9 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded which is the version in which it was made. This time, I also let the system hand in an automatic crash report. Unfortunately, it did not indicate anything such that you can relate it to this additional information. I hope you can reproduce it. Of course, If I would have been asked what I was doing in the moment, when the crash happened, I certainly would have been able to repeat the words which I was jaust writing or explain, what happened immediately before. But now, too many steps have happend in between to add such hints. This is what I crititcize on the bug reporting mechanism (which of course is another issue, I know). N.B.: I use LibreOfficeWriter with the Extension AltSearch 1.4.2. I have no idea, if the bug is related to it, but I just mention it such that you might consider it as being related in the crash - or not, I can't tell.
On pc Debian x86-64 with master sources updated today (+gtk3 rendering), I don't have crash when opening the file. Idem with LO Debian package 7.3.1 You can try to disable Altsearch and test it during some hours/days.
I installed the extension for the test and restarted LO, no crash when opening. (BTW, the last update of the extension is in March 2017 so 5 years)
(In reply to Julien Nabet from comment #7) > On pc Debian x86-64 with master sources updated today (+gtk3 rendering), I > don't have crash when opening the file. > Idem with LO Debian package 7.3.1 > > You can try to disable Altsearch and test it during some hours/days. Yes. I disabled AltSearch. Then I started Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2816f498505bab01bc0f17ef0962ece663c607c9 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded again and tried to open the file. And LibreOfficeWriter crashes. Are there any logfiles of LibreOfficeWriter? Anything how I could let LibreOfficeWriter tell more about the reason of the crash?
2 things you can try: 1) perhaps it's related to gtk3 on a console/term, type: export SAL_USE_VCLPLUGIN=gen then launch LO from this console with: soffice --writer and give a try. If you don't reproduce the crash, it's related to gtk3. If not, unrelated to gtk3 2) You can try to retrieve a backtrace by following https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace
(In reply to Julien Nabet from comment #10) > 2 things you can try: > 1) perhaps it's related to gtk3 > on a console/term, type: > export SAL_USE_VCLPLUGIN=gen > > then launch LO from this console with: > soffice --writer > and give a try. > > If you don't reproduce the crash, it's related to gtk3. > If not, unrelated to gtk3 > > 2) You can try to retrieve a backtrace by following > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux:_How_to_get_a_backtrace I gave it a try and it crashed again. However, I modified the command to start LO WriterDev instead of LibreOffice. I did it like this: export SAL_USE_VCLPLUGIN=gen libreofficedev7.4 --writer I'll upload the many lines of messages from the terminal window in a minute. Looking at it, I see that it mentions warn:desktop:7300:7300:desktop/source/app/crashreport.cxx:61: minidump generated: /home/a/.config/libreofficedev/4/crash//b36bbf05-6fbe-4e9d-7966daae-e980166e.dmp I wonder about the path containing "crash//" with two subsequent slashes. Maybe that's the cause of the trouble? I can't tell.(In reply to Julien Nabet from comment #10) > 2 things you can try: > 1) perhaps it's related to gtk3 > on a console/term, type: > export SAL_USE_VCLPLUGIN=gen > > then launch LO from this console with: > soffice --writer > and give a try. > ... I tried it out. I had to modify it to explicitly call the development version, which crashes: export SAL_USE_VCLPLUGIN=gen libreofficedev7.4 –writer LibreOfficeWriter crashed. I got a bunch of error messages in the terminal, among them a reference to warn:desktop:7300:7300:desktop/source/app/crashreport.cxx:61: minidump generated: /home/a/.config/libreofficedev/4/crash//b36bbf05-6fbe-4e9d-7966daae-e980166e.dmp The crash report mentioned in it did not exist and it can’t exist, since the path name contains two subsequent slashes! I’ll post the terminal output in a minute and try the backtrace hint after lunch.
Created attachment 179346 [details] messages from the terminal when started as suggested in comment 10
Created attachment 179354 [details] gbdtrace.log after export SAL_USE_VCLPLUGIN=gen commands issued: export SAL_USE_VCLPLUGIN=gen libreofficedev7.4 --writer --backtrace The crash happened immediately after opening the test file. Lots of error messages in the terminal (can be supplied if necessary). I hope this helps you catching and eliminating this nasty bug!
I noticed "SwTextFrame::FormatLine" in the bt but the function has 130 lines, difficult to pinpoint the exact pb. Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ? (above all profile and fonts part).
Created attachment 179427 [details] logs from a trial with 7.3 which worked I already had a parallel installation of Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: 41b4053d7a395146a488c4aba0bc17b98b0a9502 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded and I suppose that this one is the right one for “latest stable” (please correct me, if I am wrong). I started LO Writer in the described way, disabling the user profile by renaming the proper directory user. See the listing of all terminal messages and a print of gdbtrace.log in the first included file. This version 7.3 could open and edit the file in question. I stored the result under a new name and this one is legible with version 7.3, but the used development version crashes, when told to open it. Then I started LO Writer in the described way to open my supplied crash example document, see the listing of all terminal messages and a print of gdbtrace.log in the second included file. This version first offered to repair the document from the last crash, but I denied and told it to discard the changes. Then this Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2816f498505bab01bc0f17ef0962ece663c607c9 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded could open the file in question. But I could not edit it. I had to quit LO Writer. Details are shown in the second log file. No dumpfile was generated in /home/verwalter/.config/libreoffice/4/crash. I only found a dump.ini there with a time stamp from around the time of my trial.
When there's "?" or several, you can type "c" (for "continue") until there's something else than "?"
(In reply to Julien Nabet from comment #16) > When there's "?" or several, you can type "c" (for "continue") until there's > something else than "?" When in this special gbdtrace mode, I don't reach any such situation. I just repeated my above mentioned trial, but this time not giving the file to be edited aw a command line argument. Everything went fine until I had selected the offending document in the GUI. Then LibreOffice bombed out immediately, not leaving behind any gbdtrace file. Of course, I had deleted the folder ~/.config/libreoffice/4/user and everything in it before I did my trial.
Today I installed the development version of today, which is shown as Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: f775b625b497b4fa6731bddd433916dde52fbb2e CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded I am happily surprised that this version did not show the crash on all files the one before uploaded (and some more where the previous ones all failed). I'll keep an open eye in the next time (and I'll use the development version more often than in the last weeks now).
(In reply to Adalbert Hanßen from comment #18) > ... > I am happily surprised that this version did not show the crash on all files > the one before uploaded (and some more where the previous ones all failed). > > I'll keep an open eye in the next time (and I'll use the development version > more often than in the last weeks now). Good news then! :-) However since it's a dev version, do think even more than usual about making backups regularly and let's put this one to WFM. Of course, don't hesitate to reopen if you still reproduce the crash.