Created attachment 160463 [details] Example for Crash 1) Open new file in Calc 2) Run this macro for set some data: Sub setSomeData const a1=100, a2=100 dim oDoc, oSheet, oRange, i&, j&, s$, p1(a1) as variant, p2(a2) as string oDoc=thisComponent oSheet=oDoc.sheets.getByIndex(0) for i=0 to a1 'rows for array for j=0 to a2 'one row for array s=j & " - " & i p2(j)=s next j p1(i)=p2 redim p2(a2) next i oRange=oSheet.getCellRangeByPosition(0,0,a1,a2) oRange.setDataArray(p1()) End Sub 3) Then press Ctrl+F and try to find something, for example: 1 Calc crash. If you will run macro and then press for example Ctrl+A for select all (or some other operation as delete some row or column), and then you press Ctrl+F for finding, it will be OK and Calc will not crash. The same operation you can do from attached file, run macro from menu CRASH and then press Ctrl+F (or Ctrl+H) and try to find something and Calc will crash. Verze: 6.4.4.1 (x64) ID sestavení: b50bc319eca5cd5b66fbfe2ebd0d3bd1eed099b5 Vlákna CPU: 8; OS: Windows 10.0 Build 17763; Vykreslování UI: výchozí; VCL: win; Národní prostředí: cs-CZ (cs_CZ); Jazyk UI: cs-CZ Calc: threaded
Version: 7.0.0.0.alpha0+ (x64) Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc:
Not in Version: 6.3.0.4 (x86) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
This seems to have begun at the below commit. Adding Cc: to Julien Nabe; Could you possibly take a look at this one? Thanks 130e0f22ad4f3d7950e7ed836e39d17086299b89 is the first bad commit commit 130e0f22ad4f3d7950e7ed836e39d17086299b89 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Apr 15 23:32:23 2020 -0700 author Julien Nabet <serval2412@yahoo.fr> 2020-04-14 14:28:55 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-04-16 08:21:40 +0200 commit 2670e980c7dbadbdc20ff23d57ad892951edc254 (patch) tree 5d14c75f5b4a0d4d76f249430fafc6c0db406a22 parent f98b3b5b9f1b05259405833e6e528e734ded4512 (diff) tdf#132097: fix Find Previous with direction columns crashes in specific case source 2670e980c7dbadbdc20ff23d57ad892951edc254
On pc Debian x86-64 with master sources updated today, I could reproduce this. raal: I reproduce this even when reverting: author Julien Nabet <serval2412@yahoo.fr> 2020-04-14 14:28:55 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-04-16 08:21:40 +0200 commit 2670e980c7dbadbdc20ff23d57ad892951edc254 (patch) tree 5d14c75f5b4a0d4d76f249430fafc6c0db406a22 parent f98b3b5b9f1b05259405833e6e528e734ded4512 (diff) tdf#132097: fix Find Previous with direction columns crashes in specific case source 2670e980c7dbadbdc20ff23d57ad892951edc254
Raal, you were right, I must have done something wrong but when reverting the quoted patch, I don't reproduce this.
Created attachment 160468 [details] bt with debug symbols Here's a backtrace retrieved on pc Debian x86-64 with master sources updated today.
Noel/Luboš: there were comments here: https://gerrit.libreoffice.org/c/core/+/92165 Any thoughts? Indeed, I must recognize I'm a bit stuck. At worst, I can revert the commit but we'll reopen tdf#132097 put in see also.
Created attachment 160469 [details] Open document - Search for 1 - Crash
On sc/source/core/data/table1.cxx:808, I see the same kind of code before patch: 805 // We need to cache sc::ColumnBlockConstPosition per each column. 806 std::vector< sc::ColumnBlockConstPosition > blockPos( rEndCol + 1 ); 807 for( SCCOL i = 0; i <= rEndCol; ++i ) 808 aCol[ i ].InitBlockPosition( blockPos[ i ] ); (Sorry Opengrok displays blank page right now) I noticed this before this block: 785 void ScTable::GetDataArea( SCCOL& rStartCol, SCROW& rStartRow, SCCOL& rEndCol, SCROW& rEndRow, 786 bool bIncludeOld, bool bOnlyDown ) const 787 { 788 // return the smallest area containing at least all contiguous cells having data. This area 789 // is a square containing also empty cells. It may shrink or extend the area given as input 790 // Flags as modifiers: 791 // 792 // bIncludeOld = true ensure that the returned area contains at least the initial area, 793 // independently of the emptiness of rows / columns (i.e. does not allow shrinking) 794 // bOnlyDown = true means extend / shrink the inputted area only down, i.e modify only rEndRow 795 796 rStartCol = std::min<SCCOL>( rStartCol, aCol.size()-1 ); 797 rEndCol = std::min<SCCOL>( rEndCol, aCol.size()-1 );
I gave a try with https://gerrit.libreoffice.org/c/core/+/93598 I just repeat the comment of this commit to make it clear: "With this patch it doesn't crash BUT it's more guessing here than real understanding."
Following comments in quoted patch, I abandoned this one.
I incorrectly specified bug #132097 in the commit message, but fixed by https://git.libreoffice.org/core/+/58c87f8261abf4f1528a43dc501e956cb9c1d2f2%5E%21 .
Verified in Version: 7.0.0.0.alpha1+ Build ID: b6ad72a34c150df18905e47e588fd35c400dd6b9 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Luboš Luňák, thanks for fixing this issue!!
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1e38bed635d33c7c1fb56a798c0be32258f3079b tdf#132783: sc: Add UItest It will be available in 7.0.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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/3d0d78621b29fba0e95dc5b348d20bfd3234ebd3 sanitize properly Calc search bounds (tdf#132783) It will be available in 6.4.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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-6-4-4": https://git.libreoffice.org/core/commit/efabb53e4dd582ba9e475830e563d9a47c1b1eef sanitize properly Calc search bounds (tdf#132783) It will be available in 6.4.4. 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.
*** Bug 133832 has been marked as a duplicate of this bug. ***
*** Bug 133872 has been marked as a duplicate of this bug. ***
*** Bug 134740 has been marked as a duplicate of this bug. ***