Bug 132783 - Calc CRASH when Ctrl+F
Summary: Calc CRASH when Ctrl+F
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.4.1 rc
Hardware: x86-64 (AMD64) All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0 target:6.4.5 target:6.4.4
Keywords: bibisected, bisected, regression
: 133832 133872 134740 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-06 15:44 UTC by Kamil Landa
Modified: 2020-07-15 17:27 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Example for Crash (13.79 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-05-06 15:44 UTC, Kamil Landa
Details
bt with debug symbols (15.76 KB, text/plain)
2020-05-06 18:54 UTC, Julien Nabet
Details
Open document - Search for 1 - Crash (40.82 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-05-06 19:07 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kamil Landa 2020-05-06 15:44:19 UTC
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
Comment 1 Telesto 2020-05-06 16:44:57 UTC
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:
Comment 2 Telesto 2020-05-06 17:25:56 UTC
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
Comment 3 raal 2020-05-06 18:05:48 UTC
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 sha:2670e980c7dbadbdc20ff23d57ad892951edc254
Comment 4 Julien Nabet 2020-05-06 18:47:14 UTC
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 sha:2670e980c7dbadbdc20ff23d57ad892951edc254
Comment 5 Julien Nabet 2020-05-06 18:50:48 UTC
Raal, you were right, I must have done something wrong but when reverting the quoted patch, I don't reproduce this.
Comment 6 Julien Nabet 2020-05-06 18:54:33 UTC
Created attachment 160468 [details]
bt with debug symbols

Here's a backtrace retrieved on pc Debian x86-64 with master sources updated today.
Comment 7 Julien Nabet 2020-05-06 18:58:09 UTC
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.
Comment 8 Xisco Faulí 2020-05-06 19:07:33 UTC
Created attachment 160469 [details]
Open document - Search for 1 - Crash
Comment 9 Julien Nabet 2020-05-06 21:25:08 UTC
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 );
Comment 10 Julien Nabet 2020-05-06 21:30:42 UTC
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."
Comment 11 Julien Nabet 2020-05-07 09:26:34 UTC
Following comments in quoted patch, I abandoned this one.
Comment 12 Luboš Luňák 2020-05-07 13:37:19 UTC
I incorrectly specified bug #132097 in the commit message, but fixed by https://git.libreoffice.org/core/+/58c87f8261abf4f1528a43dc501e956cb9c1d2f2%5E%21 .
Comment 13 Xisco Faulí 2020-05-08 08:55:06 UTC
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!!
Comment 14 Commit Notification 2020-05-09 08:40:15 UTC
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.
Comment 15 Commit Notification 2020-05-10 07:56:47 UTC
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.
Comment 16 Commit Notification 2020-05-13 08:09:44 UTC
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.
Comment 17 Xisco Faulí 2020-06-15 13:52:29 UTC
*** Bug 133832 has been marked as a duplicate of this bug. ***
Comment 18 Xisco Faulí 2020-06-15 13:53:10 UTC
*** Bug 133872 has been marked as a duplicate of this bug. ***
Comment 19 Xisco Faulí 2020-07-15 17:27:01 UTC
*** Bug 134740 has been marked as a duplicate of this bug. ***