Summary: | Crash in: ScTable::HasAttrib(short,long,short,long,HasAttrFlags) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Tex2002ans <Tex2002ans+LibreOffice> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | aron.budea, erack, ilmari.lauhakangas, serval2412, stephane.guillou, telesto, timur, xiscofauli |
Priority: | high | Keywords: | bibisected, bisected, haveBacktrace, regression |
Version: | 5.2 all versions | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=95437 | ||
Whiteboard: | target:24.8.0 target:24.2.2.2 target:7.6.6.2 | ||
Crash report or crash signature: | ["ScTable::HasAttrib(short,long,short,long,HasAttrFlags)","ScTable::HasAttrib(short, int, short, int, HasAttrFlags) const"] | Regression By: | Markus Mohrhard |
Bug Depends on: | |||
Bug Blocks: | 113113, 133092 | ||
Attachments: |
ODS File From Extension 1078
gdb bt |
Description
Tex2002ans
2024-01-25 14:43:13 UTC
Also reproducible in Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: 229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: fr-FR (es_ES.UTF-8); UI: en-US Calc: threaded I can reproduce it back to Version: 5.2.0.0.alpha1 Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9 CPU Threads: 8; OS Version: Linux 6.1; UI Render: default; Locale: es-ES (es_ES.UTF-8) but not with 5.1.6.2 Bibisected with linux-64-5.2 to 88a0c7d01b7dfd085a0569030f97cc7de0f0d106 switch to a listener based cond format update, tdf#95437 Created attachment 192170 [details]
gdb bt
On pc Debian x86-64 with master sources updated today, I could reproduce this.
I attached bt with some console logs.
Extra info from gdb: #6 0x00007fdd4a3ca16c in ScDocument::HasAttrib (this=0x5640abef53b0, nCol1=39, nRow1=5, nTab1=-1, nCol2=16383, nRow2=5, nTab2=-1, nMask=HasAttrFlags::RightOrCenter) at /home/julien/lo/libreoffice/sc/source/core/data/document.cxx:5204 5204 if (maTabs[i]) (gdb) p maTabs $1 = std::__debug::vector of length 10, capacity 16 = {std::unique_ptr<ScTable> = {get() = 0x5640ace27ab0}, std::unique_ptr<ScTable> = {get() = 0x5640ace4c970}, std::unique_ptr<ScTable> = { get() = 0x5640ace6dc50}, std::unique_ptr<ScTable> = {get() = 0x5640ad10a590}, std::unique_ptr<ScTable> = {get() = 0x5640ad260d30}, std::unique_ptr<ScTable> = {get() = 0x5640ad8ba360}, std::unique_ptr<ScTable> = {get() = 0x5640ad8d5750}, std::unique_ptr<ScTable> = {get() = 0x5640ad8fc330}, std::unique_ptr<ScTable> = {get() = 0x5640ad906850}, std::unique_ptr<ScTable> = { get() = 0x5640ada60960}} (gdb) p i $2 = -1 (gdb) p nTab1 $3 = -1 (gdb) frame 7 #7 0x00007fdd4b293902 in ScDocShell::PostPaint (this=0x5640ab9069f0, rRanges=..., nPart=PaintPartFlags::Grid, nExtFlags=2, nMaxWidthAffectedHint=-1) at /home/julien/lo/libreoffice/sc/source/ui/docshell/docsh3.cxx:180 180 m_pDocument->HasAttrib( nCol1,nRow1,nTab1, (gdb) p rRanges $4 = (const ScRangeList &) @0x5640ad91d608: {<SvRefBase> = {_vptr$SvRefBase = 0x7fdd4bd61dc8 <vtable for ScRangeList+16>, nRefCount = 0, bNoDelete = 1}, maRanges = std::__debug::vector of length 1, capacity 1 = {{aStart = {nRow = 5, nCol = 39, nTab = -1, static detailsOOOa1 = {eConv = formula::FormulaGrammar::CONV_OOO, nRow = 0, nCol = 0}}, aEnd = {nRow = 5, nCol = 122, nTab = -1, static detailsOOOa1 = {eConv = formula::FormulaGrammar::CONV_OOO, nRow = 0, nCol = 0}}}}, mnMaxRowUsed = 5} Tabs of ranges are put to -1 on purpose here: #0 ScConditionalFormat::UpdateDeleteTab(sc::RefUpdateDeleteTabContext&) (this=0x55e3ca657ac0, rCxt=...) at sc/source/core/data/conditio.cxx:2009 #1 0x00007f65ea2dec12 in ScConditionalFormatList::UpdateDeleteTab(sc::RefUpdateDeleteTabContext&) (this=0x55e3ca6566c0, rCxt=...) at sc/source/core/data/conditio.cxx:2254 #2 0x00007f65ea7a0753 in ScTable::UpdateDeleteTab(sc::RefUpdateDeleteTabContext&) (this=0x55e3c99f1530, rCxt=...) at sc/source/core/data/table1.cxx:2003 #3 0x00007f65ea3c3a3f in ScDocument::DeleteTab(short) (this=0x55e3c9957ee0, nTab=0) at sc/source/core/data/document.cxx:711 #4 0x00007f65ebb6e50d in ScViewFunc::DeleteTables(std::__debug::vector<short, std::allocator<short> > const&, bool) (this=0x55e3c9d991d0, TheTabs=std::__debug::vector of length 1, capacity 1 = {...}, bRecord=true) at sc/source/ui/view/viewfun2.cxx:2622 #5 0x00007f65ebb223a7 in ScTabViewShell::ExecuteTable(SfxRequest&) (this=0x55e3c9d98eb0, rReq=...) at sc/source/ui/view/tabvwshf.cxx:387 Eike: following my previous comments, I thought about this patch: diff --git a/sc/source/ui/docshell/docsh3.cxx b/sc/source/ui/docshell/docsh3.cxx index 922c2c358a26..f8ee04ef8d50 100644 --- a/sc/source/ui/docshell/docsh3.cxx +++ b/sc/source/ui/docshell/docsh3.cxx @@ -117,6 +117,8 @@ void ScDocShell::PostPaint( const ScRangeList& rRanges, PaintPartFlags nPart, sa SCCOL nCol1 = rRange.aStart.Col(), nCol2 = rRange.aEnd.Col(); SCROW nRow1 = rRange.aStart.Row(), nRow2 = rRange.aEnd.Row(); SCTAB nTab1 = rRange.aStart.Tab(), nTab2 = std::min<SCTAB>(nMaxTab, rRange.aEnd.Tab()); + if (nTab1 < 0 && nTab2 < 0) + continue; if (!m_pDocument->ValidCol(nCol1)) { I tested it locally and it prevents LO from crashing. Any thoughts here? I think it should even be + if (nTab1 < 0 || nTab2 < 0) (i.e. any deleted or otherwise set negative sheet can't form a valid range) but otherwise looks like a sensible approach. Question remains why this PostPaint() is called at all for an invalid range.. (In reply to Eike Rathke from comment #8) > I think it should even be > > + if (nTab1 < 0 || nTab2 < 0) > > (i.e. any deleted or otherwise set negative sheet can't form a valid range) > but otherwise looks like a sensible approach. Thank you for the feedback. > Question remains why this PostPaint() is called at all for an invalid range.. bt shows who call PostPaint. Should I submit a patch accordingly to your remark or do you prefer to take a look at the hierarchy calls first? *** Bug 160022 has been marked as a duplicate of this bug. *** band-aid submitted here: https://gerrit.libreoffice.org/c/core/+/164354 Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e19340d13ca40ede3fe671b7d2b710e0a53a0d31 tdf#159373: band-aid for crash in: ScTable::HasAttrib 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. Stops the crashing for me... Thanks Julien Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/2ffba480017a44522cb6c8946d75f6ad5f1c9026 tdf#159373: band-aid for crash in: ScTable::HasAttrib It will be available in 24.2.3. 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. Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/71f62cff7e74f8663052230cf1279d05a9579411 tdf#159373: band-aid for crash in: ScTable::HasAttrib It will be available in 7.6.7. 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. Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/36a169c10f0457c30a0d327fda585c4decb33532 tdf#159373: sc_uicalc: Add unittest 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. Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-6-6": https://git.libreoffice.org/core/commit/b2f5db9d7c590a0dbbb6062008520a84854d582c tdf#159373: band-aid for crash in: ScTable::HasAttrib It will be available in 7.6.6. 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. Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-24-2-2": https://git.libreoffice.org/core/commit/40f6e9a45edae06556e1d1a26237dc2ab12bc0ca tdf#159373: band-aid for crash in: ScTable::HasAttrib It will be available in 24.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. @Stragu What's the policy here? The bug is drawing unnecessary attention, IMHO. It's marked NEW, importance high/major, title crash. With whiteboard showing: patches committed. Which leads to even more 'investigation'. What is going on... To conclude, this is actually 'fixed' with the band-aid in place. I surely grasp that band-aid being band-aid; intended as a temporal fix. Not permanent one. However a band-aid does de facto remove a part of the urgency for true fix. Is a new bug not better to explain the true state of affairs? There is no crash with the band-aid in place. Alternative would be to relabel the bug title and maybe adjusting the importance to represent the actual state. Julien, could you please close this report as "resolved - fixed" and open a follow-up report with a short summary of what remains to be fixed? Probably the best way forward. Thanks Telesto. (In reply to Stéphane Guillou (stragu) from comment #20) > Julien, could you please close this report as "resolved - fixed" and open a > follow-up report with a short summary of what remains to be fixed? Probably > the best way forward. > Thanks Telesto. Except investigating about "PostPaint() called for an invalid range" as Eike indicated in comment 8 and it's a dev task not a symptom, I don't know what to put on a new bugtracker. |