Created attachment 194273 [details] Example file Opening attached file (minimized further from bug 161215 's attachment 194272 [details] ) crashes after a few seconds. Seems to have started in: https://git.libreoffice.org/core/+/ff7f1b59e22092d8548459e75fe912db852f056f commit ff7f1b59e22092d8548459e75fe912db852f056f [log] author Mike Kaganski <mike.kaganski@collabora.com> Fri Feb 09 11:56:19 2024 +0600 committer Michael Stahl <michael.stahl@allotropia.de> Mon Feb 19 12:39:35 2024 +0100 tdf#159565 prerequisite: make hidden sections have zero-height frames Before this opening the file endless looped, about that see bug 161215
Reproduced in: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Document Recovery dialog frozen afterwards. https://crashreport.libreoffice.org/stats/crash_details/921f039f-f34b-41b5-bd66-54d9c4f2b5ce Also recent daily build: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ae798781ef4df7a1fdef13af0bc459bf4f6e7b4c CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
(In reply to Stéphane Guillou (stragu) from comment #1) A change from a hard freeze to an immediate crash is a *regression*? I'm put to the "Regression By" field, which is counted to *regressions* I created, no matter what you put into Keywords. And then, it's a *critical* change? Wow. Please, let's use some common sense :-D
Created attachment 194276 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
(In reply to Mike Kaganski from comment #2) > (In reply to Stéphane Guillou (stragu) from comment #1) > > A change from a hard freeze to an immediate crash is a *regression*? I'm put > to the "Regression By" field, which is counted to *regressions* I created, > no matter what you put into Keywords. I did not populate the Regression field. > And then, it's a *critical* change? > Wow. Please, let's use some common sense :-D I only go by the flow chart we try to follow for some consistency, in which all crashes should go with severity = critical. https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Feel free to change the value if you disagree, or suggest improvements to that process.
Stéphane: reading the flowchart, I suppose you used the path: Yes, No, No, No => Medium, critical I think we should add another question in this case: is it specific to a file or is it for any file? if concerns any file => Critical else (so specific case) => Normal or Major (but a least not Critical) We could refine even further by asking if the bug happens on a specific OS or on all OSes. (even if in our case, it's not OS specific considering the bt). Now I agree it's very subjective and it's not easy to find a right balance.
Let's remove Mike from "Regression by" field since it's not a regression per se (see Mike's comment 2). I prefer indeed a "clear crash" instead of a hang at least because the bt retrieved isn't random :-)
(In reply to Julien Nabet from comment #5) > Stéphane: reading the flowchart, I suppose you used the path: > Yes, No, No, No => Medium, critical > > I think we should add another question in this case: > is it specific to a file or is it for any file? > if concerns any file => Critical > else (so specific case) => Normal or Major (but a least not Critical) > > We could refine even further by asking if the bug happens on a specific OS > or on all OSes. > (even if in our case, it's not OS specific considering the bt). > > Now I agree it's very subjective and it's not easy to find a right balance. Probably best to add comments on https://wiki.documentfoundation.org/File_talk:Prioritizing_Bugs_Flowchart.jpg, or even start the conversation on the QA mailing list, so ideas don't get lost and this report stays on focus. Happy to reply in either.
(In reply to Stéphane Guillou (stragu) from comment #7) > ... > > Now I agree it's very subjective and it's not easy to find a right balance. > Probably best to add comments on > https://wiki.documentfoundation.org/File_talk:Prioritizing_Bugs_Flowchart. > jpg, or even start the conversation on the QA mailing list, so ideas don't > get lost and this report stays on focus. Happy to reply in either. Ok done.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e607bf096d4fb182388ccaefb1179cdd924af02a tdf#161217 sw: layout: don't move into to-be-deleted section frame It will be available in 24.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.
fixed on master; it's a floating-table problem
On pc Debian x86-64 with master sources updated today (3b71e059c1b3d32110152feeb0c85d51e2775ec7), I don't reproduce this. Thank you Michael!
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/a7548d6b38a9b075f31f5955d1512d9ff5017d66 tdf#161217 sw: layout: don't move into to-be-deleted section frame It will be available in 24.2.5. 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.