Created attachment 175069 [details] test ODS Open attached ODS (prepared for bug 53489). Delete row 3. Crash. Repro in Linux and Windows in LO 7.3+. Regression.
Bug seems not to be reproducible, happens sometimes, I had it with 7.3+ in Windows and also with 7.1 in Linux. But I couldn't bibisect it.
Seems that crash happens only with experimental "Very large spreadsheets", although it's not large, very simple ODS with chart. Repro 7.0 in Linux.
Confirm the crash in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 80a47aae1419842f4496f02028e2b49763aea25b CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded But I don't think that High & Critical is a correct Importance for experimental feature. It's just a bug that should be fixed Xisco?
(In reply to Roman Kuznetsov from comment #3) > Xisco? +1
It took me a while to find out that it's Jumbo, nothing would point at it. This definitely is not Normal Nor Medium. Similar logic is with Outline, yes experimental, but if you have basic functions not working and you don't know why, it's important. I generally think that bugs should be regarded the same, regardless of they are Experimental - unless that is dumpster not to ever be resolved or put into use. If it weren't Experimental if would have been highest. QA should not make life harder to itself, like oh I keep Experimental knowing those bugs and crashes that mix with others are normal ro happen for a long time.
Created attachment 175082 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today + "jumbo" option I could reproduce this.
Roman and Xisco, please CC someone who would and could resolve this.
Noel: thought you might be interested in this one. Here's something weird: julien@debianamd:~/lo/libreoffice$ git grep -n MAXROWCOUNT1 sc/source/core/data/column2.cxx:1663: if (maCells.size() != MAXROWCOUNT1) sc/source/core/data/column2.cxx:1670: if (maCellTextAttrs.size() != MAXROWCOUNT1) sc/source/core/data/column2.cxx:1677: if (maBroadcasters.size() != MAXROWCOUNT1) sc/source/filter/lotus/lotattr.cxx:184: // Actually with the current implementation of MAXROWCOUNT1>=64k and nRow sc/source/ui/view/viewdata.cxx:1335: const sal_Int32 kMax = 23 * 1024 * 1024; // current MAXROWCOUNT1 is 1024*1024=1048576 so MAXROWCOUNT1 isn't defined at all?
(In reply to Julien Nabet from comment #8) > Noel: thought you might be interested in this one. > No, not at all. > > so MAXROWCOUNT1 isn't defined at all? It is inside an #ifdef
Indeed, I had overlooked the ifdef Anyway, uncc myself since I can't help here.
This still crashes somewhere else than comment #6 points to. Adding bibisectRequest.
(In reply to Luboš Luňák from comment #11) > This still crashes somewhere else than comment #6 points to. Adding > bibisectRequest. Hi Lubos, The original steps do not crash for me in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f0c26dc83448a934af5383f9f6b7a607c334744 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Jumbo Could you please explain the steps to reproduce the crash ?
The crash is an assertion failure in ScChart2DataSequence::Notify(), optimized build passes fine. I don't know if bibisect builds have assertions enabled, if not then it's not possible to bibisect.
(In reply to Luboš Luňák from comment #13) > The crash is an assertion failure in ScChart2DataSequence::Notify(), > optimized build passes fine. I don't know if bibisect builds have assertions > enabled, if not then it's not possible to bibisect. Unfortunately not
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d0a42ce9b1033a200f8d354c1abf8c3b0d569f46 avoid debug build failing on an assert for tdf#144537 It will be available in 7.4.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.
I see no problem related to jumbo sheets. There's still the assert, which points to some small UI problem, but that has been there for years, and I don't know how to fix that, so I've downgraded the assert until somebody actually complains about the problem.
Confirm Crash with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 42c5506a9e9ef58efd8193a193464e3b49d481ca CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Jumbo Everything OK (no crash) with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 2bb10a827ac13d0caf009e8526ccd9f17dc71653 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Jumbo
916383b807c5d32afdfa1bbe501f9eded5a22a86 is the first bad commit commit 916383b807c5d32afdfa1bbe501f9eded5a22a86 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Feb 10 13:14:19 2022 +0100 source 8bb457d17ef970676f60976cc4e2de9c9f5340c0 author Luboš Luňák <l.lunak@collabora.com> Mon Feb 07 16:09:58 2022 +0100 committer Luboš Luňák <l.lunak@collabora.com> Thu Feb 10 11:59:39 2022 +0100 tree fa9d46cde0577f4b26bd9bedada7ef309ad59ea9 parent a6eddceda5d376cd73922123a3bb3a5683307c41 [diff] dynamic logarithmic columns in ScBroadcastAreaSlotMachine That one fixed different bugs. Thanks Luboš.
*** Bug 149968 has been marked as a duplicate of this bug. ***