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.
I was wrong in comment 15 when saying that git master (ff0eebbac4c03e820485ccb7ea1f6e9f06606a09) doesn't crash. It does crash! With commit cc9574aa24614d168ead5ace2fcc96267347279f it seems to run stable so far, so I think it can be bisected. BUT, going from good to bad step by step will not work, because that will take forever. I would need a list of Commits thats between the two mentioned commits and a way to directly jump to any given commit. So I can always devide the range by two, finding the culprit "faster" (it will still take a looooong time)... Here's an updated list of builds that crash: 25.8.0.4 -> no crash, no linktarget 25.8.1.1 -> no crash, no linktarget 25.8.2.2 -> no crash, no linktarget 25.8.3.1 -> crash, first build that brings the linktarget (for example: "_blank") back 25.8.3.2 -> crash 25.8.4 -> crash 26.2.0 Beta 1 -> crash 26.2.0.3 -> crash 26.2.1.0.0+ (X86_64), Build ID: ff0eebbac4c03e820485ccb7ea1f6e9f06606a09 -> crash 26.8.0.0.alpha0+ (X86_64), Build ID: 680(Build:0) -> crash
(In reply to bugzilla2 from comment #18) > I was wrong in comment 15 when saying that git master > (ff0eebbac4c03e820485ccb7ea1f6e9f06606a09) doesn't crash. It does crash! > > With commit cc9574aa24614d168ead5ace2fcc96267347279f it seems to run stable > so far, so I think it can be bisected. > > BUT, going from good to bad step by step will not work, because that will > take forever. I would need a list of Commits thats between the two mentioned > commits and a way to directly jump to any given commit. So I can always > devide the range by two, finding the culprit "faster" (it will still take a > looooong time)... It's true that if reproducing the issue is difficult, it can take a long time. This is the way you can find source commits in the bibisect repositories: https://wiki.documentfoundation.org/QA/Bibisect#Checking_out_a_specific_commit_based_on_source_hash However, it is only faster, if there are a small number of commits within the range, like 100-200. There is no difference between what you say about doing the division manually vs. doing the bibisect.
Hi Buovjaga, I found the troublesome commit now: commit 90f50c4ffc415ede1a8d0399e574b5d92cb4d4cc Author: Jenkins Build User <tdf@tb102-2> Date: Wed Dec 24 00:21:18 2025 +0100 source 23afeaedf4d4a03943338fc39ae41f5c423e5997 23afeaedf4d4 tdf#168431: Release solar mutex when sending window message to main thread I had a short look into that commit and it seems to change the way LibreOffice handles threads. And I guess Java runs in a different thread than main UI. According to my list, the commit immediately before the troublesome commit would be "d29d9cbb3e66497e20752baff550418cf92743b8", and on this Level, LibreOffice runs fine for me since 6 days. I'm curious what happens now :D Hopefully all the time I spent with bibisecting this wasn't wasted ...
Thanks, let's ask Mike what he thinks.
Which Java is used? The version and the vendor.
(In reply to Mike Kaganski from comment #22) > Which Java is used? The version and the vendor. WritingTool 26.4-SNAPSHOT (2026-03-03 22:20:07 +0000) OS: Windows 11 10.0 (amd64) LibreOffice 26.2.0.3 Java version: 21.0.10 (Azul Systems, Inc.) Java max/total/free memory: 1024MB, 187MB, 100MB
https://gerrit.libreoffice.org/c/core/+/201007
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c5174cb7597d2c0ddbc356b3456a92e96707b71a tdf#170205: drop NoYieldLock mode It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/0e6b401d605d8ef175aeec392b4a5afc033613dc tdf#170205: drop NoYieldLock mode It will be available in 26.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks a lot to Mike for fixing the bug and Buovjaga for the help. I use the master since 4 days now, and no crash so far :) Is it too late to backport the fix to 25.8.6.2, which will be ready soon? Would be good to have the fix in stable-versions too, not only in 26.x.