Description: LibreOffice 25.8.4 crashes quiet often. 24.8.7 did run absolutely stable on same system. Steps to Reproduce: There are no reproduction-steps, because it seems to happen totally randomly. Last crash was after deleting 2 lines from a document and saving it. But it didn't crash immediately after saving but with quite a delay. Often it crashes with not doing anything that moment. Actual Results: LibreOffice crashes. Dump is produced (attached) Expected Results: LibreOffice should not crash Reproducible: Sometimes User Profile Reset: No Additional Info: Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: de-AT (de_AT); UI: de-DE Calc: CL threaded
Created attachment 204902 [details] Crashdump 1
Created attachment 204903 [details] Crashdump 2
I have updated LibreOffice to version 25.8.4.2 (stable) and the alpha version 26.8.0.0. During testing, I did not encounter any crashes in either version. The only thing I noticed was a brief 5–7 second freeze in Calc when trying to enter text in a field immediately after launch. After closing Calc and reopening it, this freeze was no longer observed. This is my observation as a beginner. My environment: Windows 11 Pro (64-bit),23H2, Skia/Raster rendering (Skia Backend: GaneshGL)., locale de-AT/de-DE.
In the dumps one can see that "java_uno" is involved in the crashes. It seems like that the crash only occurs when java is enabled (which than enables my installed "writingtool plugin). So, without Java being enabled, I think this bug doesn't occur. It seems like something has changed in how Java is handled in LibreOffice after 24.8 series. In 24.8 the same java version and the same writing-tool versions runs without any crashes. Using the "java*.dll"-Files from 24.8.7 in 25.8.4 doesn't cure the problem. Java still works with the older dll-files in the new environment, but the crash is still there.
So far I noticed this crashes in the following versions: 25.8.3 25.8.4 26.2.0 Beta 1 I will continue to try older versions to see when this bug was introduced ... 24.8.7 is the last version that run stable for me so far. Each test with the same java and writingtool version.
I suspect the testing in comment 3 did not take into account that one needs to install WritingTool from https://github.com/writingtool-org/writingtool/releases as the reporter did not indicate it clearly.
(In reply to Buovjaga from comment #6) > I suspect the testing in comment 3 did not take into account that one needs > to install WritingTool from > https://github.com/writingtool-org/writingtool/releases as the reporter did > not indicate it clearly. Yeah, sorry for that. But I didn't know its related to WritingTool myself when I created the BugReport. I just opened the Bugreport because I couldn't find another way to upload the crashdumps. I updated the title now so its more precise.
After several more tests, it seems that 25.8.3.1 is the first build that has the bug. 25.8.2.2 did run fine (even though not tested for ages). Also interesting, 25.8.3.1 is the first 25.8 build that added back the "frame"-option, that was missing in previous 25.8 builds. As I do use the "link"-dialogue a lot in my tests and work, there might be a connection between the bug and the reintroduced "frame"-option in the link-dialogue. Since I absolutely need the frame-option, I can not use 25.8.2.2 longer for more intense tests, but all builds that crashed, crashed sooner or later during my link-copy-paste test, so I am quite sure, that 25.8.3.1 is the first build with that bug. PS: I can not set 25.8.3.1 as the first version with the bug in the meta data above...
Then it must be something backported to 25.8 and could be bibisected with the 26.2 repository: https://wiki.documentfoundation.org/QA/Bibisect https://wiki.documentfoundation.org/QA/Bibisect/Windows https://bibisect.libreoffice.org/win64-26.2-2022 You can install WritingTool when launching the bibisect version and it will stay installed there.
Can't that be bibisected in the 25.8 branch too? Because in 25.8 I already know at least the first build that introduced that behavior. In 26.2 I would have to start from scratch again, as I only know that it does happen in 26.2 Beta 1 so far. Maybe all 26.2 builds have that bug, can it than be bibisected at all with that branch? As far as I understood, bibisecting means I have to find out not only the first build that has the issue, but the exact commit that caused the regression? That for I need a working and a non working build, and I am not sure if a "working" 26.2 build exists ... If I totally misunderstood the process of bibisecting please tell me. Never did that before ...
(In reply to bugzilla2 from comment #10) > Can't that be bibisected in the 25.8 branch too? Because in 25.8 I already > know at least the first build that introduced that behavior. In 26.2 I would > have to start from scratch again, as I only know that it does happen in 26.2 > Beta 1 so far. Maybe all 26.2 builds have that bug, can it than be > bibisected at all with that branch? > > As far as I understood, bibisecting means I have to find out not only the > first build that has the issue, but the exact commit that caused the > regression? That for I need a working and a non working build, and I am not > sure if a "working" 26.2 build exists ... > > If I totally misunderstood the process of bibisecting please tell me. Never > did that before ... It would still be the same ~13 steps. The benefit is that you immediately get the "mother" commit.
(In reply to bugzilla2 from comment #10) > As far as I understood, bibisecting means I have to find out not only the > first build that has the issue, but the exact commit that caused the > regression? That for I need a working and a non working build, and I am not > sure if a "working" 26.2 build exists ... You first check with `git checkout oldest` that the issue is not seen and then with `git checkout master` that it is seen. I'm not sure, if it is still needed, but as the 26.2 repository was recently rebuilt with the new Visual Studio 2022 baseline, I had to manually add the "oldest" tag: git tag oldest cc9574aa24614d168ead5ace2fcc96267347279f We can find out the first commit by saying `git log --reverse`
I do not understand all the tech-talk in the last comments, but I tested 26.2.0.0, Alpha 1 now, and this build also crashes. As there are no older 26.2 builds to test, I do not think that there is a "working" build in the 26.2 branch and that for I think it can not be used for bibisecting as I think a "working" build before the "bad" commit is needed? As said, I have no experience with bibisecting, so tell me if my guesses are wrong. I just want to avoid to spend hours of testing if the 26.2 branch can not deliver any answers ... Sadly the issue can't be reproduced with just a couple of clicks, its always quite a lot of time needed till a crash happens. So testing hundreds of commits might take days of testing ...
I assume you don't have the newer Powershell 7 installed. 1. Open Powershell 5 2. Give this command to install the latest Powershell: winget install --id Microsoft.PowerShell --source winget 3. Give this command to install git: winget install -e --id Git.Git 4. Close the old Powershell window and use Windows Start Menu to launch Powershell 7 5. Go to some directory, could be the root of C: drive itself, so `cd C:\` and clone the 26.2 bibisect repository with: git clone https://bibisect.libreoffice.org/win64-26.2-2022.git 6. After the clone has finished, say cd win64-26.2-2022 7. Now say git tag oldest cc9574aa24614d168ead5ace2fcc96267347279f 8. Now give these chained commands, install WritingTool and try to make it crash: git checkout oldest && instdir\program\soffice 9. If it does not crash, you should be able to bibisect the issue. Next use this and hopefully it *will* exhibit the crash: git checkout master && instdir\program\soffice 10. Next start the bibisecting with: git bisect start master oldest && instdir\program\soffice 11. Whenever you don't get the crash say: git bisect good && instdir\program\soffice 12. Whenever you do see the crash, say: git bisect bad && instdir\program\soffice 13. When the process is finished after something like 13 steps, it will display the first bad commit. Select and copy all the lines in this final output (you can copy by right-clicking, it gets put into the clipboard immediately) and paste here to a comment for us to inspect. Let me know, if you need further help. I am available for a screensharing call as well.
I stopped at point 9, because with Git Master (ff0eebbac4c03e820485ccb7ea1f6e9f06606a09), I didn't see a crash. As those tests are extremely(!) time consuming and the bug might be fixed in Git Master, I'll check out the next 26.2 RC (26.2.0.4? or 26.2.1.1) when it becomes available to see if the bug is fixed there too. No point in doing endless bisecting when the bug might be already fixed ... I hope it is fixed, because otherwise it could mean that the bug can't be reproduced in the development/git versions ...
Btw, installing the WritingTool AddOn was not possible at Step 8. That always throws error messages of not being able to write a file. Had to copy the user-profile over from stable-build.
You can try a daily build, Win-x86_64@tb103-1-TDF from https://dev-builds.libreoffice.org/daily/master/current.html It installs with a separate user profile.