Bug Hunting Session
Bug 106456 - LibreOffice Calc crashed on inserting formula
Summary: LibreOffice Calc crashed on inserting formula
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All All
: highest critical
Assignee: Markus Mohrhard
URL:
Whiteboard: target:5.4.0 target:5.3.2 target:5.2.7
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2017-03-09 12:45 UTC by Nikolay
Modified: 2017-04-06 14:18 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Contains data for demonstration of the bug (11.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-03-09 12:45 UTC, Nikolay
Details
gdb backtrace (187.40 KB, text/x-log)
2017-03-09 14:27 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay 2017-03-09 12:45:45 UTC
Created attachment 131772 [details]
Contains data for demonstration of the bug

In the attached file, select the range C13: C26, copy and paste it into a new document (default is cell A2). LibreOffice Calc crashed if you insert into rows 1 to 12 (-1 from the beginning of the selection) and to columns c A to C (not to the right of the selection)

The problem occurs when a sheet name is specified in the formula.
Comment 1 Xisco Faulí 2017-03-09 13:53:27 UTC
Confirmed in

Versión: 5.3.1.1
Id. de compilación: 72fee18f394a980128dc111963f2eefb05998eeb
Subpr. de CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; 
Configuración regional: es-ES (es_ES); Calc: group

and

Version: 5.4.0.0.alpha0+
Build ID: d3676ceeec55a41337ce5e6bc596f4f100d0638e
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Error message:
multi_type_vector::get_block_position#795: block position not found! (logical pos=18446744073709551615, block size=5, logical size=1048576)
Comment 2 Xisco Faulí 2017-03-09 13:57:47 UTC
Reproduced in

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)

but not in

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
Comment 4 Xisco Faulí 2017-03-09 14:27:10 UTC
Created attachment 131776 [details]
gdb backtrace
Comment 5 Aron Budea 2017-03-11 00:34:34 UTC Comment hidden (bibisection)
Comment 6 Aron Budea 2017-03-11 00:41:11 UTC
This crash started with Markus' commit referenced below. The crash is actually a Fatal Error with the message:
"multi_type_vector::get_block_position#795: block position not found!
(logical pos=4294967295, block size=5, logical size=1048576)"

Maybe some kind of overflow?

https://cgit.freedesktop.org/libreoffice/core/commit/?id=c8ad72703b74b7338c5f8dd1fe0275822b1e45f0
author		Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-02-18 05:03:11 (GMT)
committer	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-02-18 07:48:27 (GMT)

"don't fill the matrix cell by cell, tdf#67071"
Comment 7 Aron Budea 2017-03-11 01:20:04 UTC
The direct cause of the crash is that in convertToTokenArray(...), nRow is -1, which is passed in through pSrcDoc->FillMatrix(...) all the way to the mdds function.

The place of the first FillMatrix(...) call:
http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/externalrefmgr.cxx#1615

And this is where -1 becomes 4294967295 in an SCROW -> StoreT::size_type type conversion:
http://opengrok.libreoffice.org/xref/core/sc/source/core/data/column2.cxx#2365
Comment 8 Julien Nabet 2017-03-11 17:35:43 UTC
Aron/Xisco: how did you get the bt?
Indeed, I got a popup error. If I Ctrl-C gdb, i got a bt from the code which manages popup then if I continue gdb, it stops without bt.
popup may be useful but in this case, it prevents me to retrieve a bt.
Comment 9 Aron Budea 2017-03-12 01:08:10 UTC
(In reply to Julien Nabet from comment #8)
> Aron/Xisco: how did you get the bt?

I debugged in the code. The message contains the line number where the exception is triggered (but it's in the mdds source code, and a bit difficult to find).

This is the line:
https://gitlab.com/mdds/mdds/blob/master/include/mdds/multi_type_vector_def.inl#L795
Comment 10 Markus Mohrhard 2017-03-13 11:44:57 UTC
My code is just exposing a bug in another place.
Comment 11 Commit Notification 2017-03-14 00:57:04 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=951fcc6556346e19a028443c70dea27d0cbc9c36

tdf#106456, don't try to use invalid ranges in external ref code

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2017-03-14 07:08:03 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8137bcb9c2915b179c541154cee050a11c54ba59

add test for tdf#106456

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2017-03-14 13:55:59 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=20bcaeb0f8509e4b12d72d4612b5f3c9bfde3489&h=libreoffice-5-3

tdf#106456, don't try to use invalid ranges in external ref code

It will be available in 5.3.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Nikolay 2017-03-21 04:24:39 UTC
In the version 5.2.x (5.2.6) won't corrected?
Comment 15 Aron Budea 2017-03-21 06:55:52 UTC
The fix for 5.2 is in gerrit at the moment: https://gerrit.libreoffice.org/#/c/35188/

Once it's merged, it'll be part of the next 5.2 update (5.2.7 is planned to be the final one).
Comment 16 Commit Notification 2017-04-06 14:18:48 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=057889ab6daa159558f5a90bc03d987500d65b04&h=libreoffice-5-2

tdf#106456, don't try to use invalid ranges in external ref code

It will be available in 5.2.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.