Bug 93196 - Switching spreadsheet tab triggers crash, no data provided
Summary: Switching spreadsheet tab triggers crash, no data provided
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Eike Rathke
URL:
Whiteboard: target:5.2.0 target:5.1.2 target:5.0.6
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2015-08-06 13:36 UTC by rlk
Modified: 2016-10-25 19:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Switch to PR tab, watch LibreOffice crash. (2.47 MB, application/vnd.oasis.opendocument.spreadsheet)
2015-08-06 13:36 UTC, rlk
Details
Minimal crash during recalculate (182.47 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-01-30 23:20 UTC, rlk
Details
bt part (238.60 KB, text/plain)
2016-01-31 10:57 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rlk 2015-08-06 13:36:23 UTC
Created attachment 117714 [details]
Switch to PR tab, watch LibreOffice crash.

Using openSUSE RPM's.  Open attached database, switch to PR tab.  LibreOffice crashes.  No crash dialog provided, so I don't have any more data.

Works fine on 4.2 (haven't specifically tested versions in between; they all have other problems with this spreadsheet that I've filed separately).
Comment 1 Cor Nouws 2015-08-08 14:04:40 UTC
Thanks for your report Rik.

Opening takes long in 5.0.0.5 on Ubuntu 32 bits.
And indeed, switching to tab PR crashes LibreOffice.

Set to New.

Cheers - Cor
Comment 2 Cor Nouws 2015-08-08 14:11:35 UTC
Opening in 4.4.5 takes long too.
But does not crash.
Comment 3 rlk 2015-08-08 17:10:20 UTC
[rlk, not rik]

If you think this one takes a long time to open, you should see the full one before I removed 3/4 of the pages.
Comment 4 Michael Weghorn 2015-08-08 20:19:03 UTC
(bi)bisect result (using the bibisect-50max repository):
 265b49b3abfb8ea9f983f086fd41afe314ffa54e is the first bad commit
commit 265b49b3abfb8ea9f983f086fd41afe314ffa54e
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Wed May 27 19:48:36 2015 +0800

    source-hash-b68987558068f88fa8016e5bd2d62f57d27d0c19
    
    commit b68987558068f88fa8016e5bd2d62f57d27d0c19
    Author:     Eike Rathke <erack@redhat.com>
    AuthorDate: Mon Mar 2 16:11:01 2015 +0100
    Commit:     Eike Rathke <erack@redhat.com>
    CommitDate: Thu Mar 5 11:44:53 2015 +0100
    
        remove SC_START_INDEX_DB_COLL binary file format legacy
    
        There's no ocName that should be ocDBArea instead anymore.
    
        Change-Id: Idbbb62330bfdc5c4e83f99436490e12d90cfd1d4

:040000 040000 c76eff9ca0165e9284a15f909a0cf5f6258aeb7a a4b0070a3269c8efc93557ef50425be3edf61445 M	opt

---

$ git bisect log
# bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
# good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
git bisect start 'latest' 'oldest'
# good: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
git bisect good 0c30a2c797b249d0cd804cb71554946e2276b557
# bad: [2ce02b2ce56f12b9fcb9efbd380596975a3a5686] source-hash-17d714eef491bda2512ba8012e5b3067ca19a5be
git bisect bad 2ce02b2ce56f12b9fcb9efbd380596975a3a5686
# bad: [e4deb8a42948865b7b23d447c1547033cb54535b] source-hash-ce46c98dbeb3364684843daa5b269c74fce2af64
git bisect bad e4deb8a42948865b7b23d447c1547033cb54535b
# bad: [15e8b5cc6b4784fecd63b2a5a04ac086b3e9fc01] source-hash-26b500afcaed704db7a300836f466517c309ee77
git bisect bad 15e8b5cc6b4784fecd63b2a5a04ac086b3e9fc01
# bad: [534715525a93b0d7d56ba123d253c927cccf0afe] source-hash-40c9a46b78b8919aae82dd9b94774d63bb9cb4e6
git bisect bad 534715525a93b0d7d56ba123d253c927cccf0afe
# good: [c255ade961c9628f72d2fbca268fdf3a4e5f60c2] source-hash-4bdbea5447f36beb9cc33df173a89a49a9918290
git bisect good c255ade961c9628f72d2fbca268fdf3a4e5f60c2
# bad: [2b4739cd51404149b1279b86643f1fee719de667] source-hash-8ee20e2691aa6f67c67d40c61a8cd1569458b5a8
git bisect bad 2b4739cd51404149b1279b86643f1fee719de667
# good: [7718aa1e7df77b45a78cf92475ccb7d9bd45440e] source-hash-a1778a4b4551102d6319a77238196a6822b84187
git bisect good 7718aa1e7df77b45a78cf92475ccb7d9bd45440e
# good: [91484d07faa5153c3737e893de44ec6db0eb91d5] source-hash-4d3ba6eeed42083e9c3f3a0dcfa4c77cbed9a146
git bisect good 91484d07faa5153c3737e893de44ec6db0eb91d5
# good: [ed6c5ddc79c6d26fed6396b1cce24a7cb2c457b1] source-hash-725fdd9214190da2425de9bc69264cb5b38e0443
git bisect good ed6c5ddc79c6d26fed6396b1cce24a7cb2c457b1
# good: [66e7cba609bcefda5eee99ab2f2e51c46af10daa] source-hash-8d78888a0c62641284d5e5fbe42cb3b950e22683
git bisect good 66e7cba609bcefda5eee99ab2f2e51c46af10daa
# bad: [626bd21610465c4555a429e4b946315a5fb5b8e9] source-hash-962e14e94d081e587c554e762910c0983f6a139b
git bisect bad 626bd21610465c4555a429e4b946315a5fb5b8e9
# bad: [265b49b3abfb8ea9f983f086fd41afe314ffa54e] source-hash-b68987558068f88fa8016e5bd2d62f57d27d0c19
git bisect bad 265b49b3abfb8ea9f983f086fd41afe314ffa54e
# first bad commit: [265b49b3abfb8ea9f983f086fd41afe314ffa54e] source-hash-b68987558068f88fa8016e5bd2d62f57d27d0c19


@Eike: Could you possibly have a look at this?
Comment 5 Julien Nabet 2015-08-22 17:54:13 UTC
Laurent: Like https://bugs.documentfoundation.org/show_bug.cgi?id=93571#c5, I can't even open the file to test it and retrieve a bt because it consumes too much memory. (i5 with 6GB and I closed all apps, Icedove and Iceweasel included!)
Comment 6 rlk 2015-08-22 18:07:08 UTC
This spreadsheet is a memory hog, but it shouldn't be that bad.  On my system, it takes about 2.2 GB of virtual memory with LibreOffice 5.0.1.1.
Comment 7 Julien Nabet 2015-08-22 18:09:28 UTC
(In reply to rlk from comment #6)
> This spreadsheet is a memory hog, but it shouldn't be that bad.  On my
> system, it takes about 2.2 GB of virtual memory with LibreOffice 5.0.1.1.

I must recognize, I build with enable-dbgutil to have max information when retrieving bt.
However, perhaps there's a pb with recent master sources which causes such consumption of memory.
Comment 8 Robinson Tryon (qubit) 2015-12-13 11:13:21 UTC Comment hidden (obsolete)
Comment 9 rlk 2015-12-25 23:58:22 UTC
Still present in 5.0.4, openSUSE 42.1 RPMs.
Comment 10 rlk 2015-12-26 01:36:25 UTC
With 5.1.0RC1, I'm able to switch tabs without it crashing, but if I force recalculation (F9) it then crashes (again, no information provided).  I can file a new bug if desired, but the behavior is basically much the same on the same spreadsheet.

If I immediately recalculate after loading (without switching tabs) it also crashes, with both 5.0 and 5.1.
Comment 11 rlk 2016-01-30 23:20:08 UTC
Created attachment 122292 [details]
Minimal crash during recalculate

I've cut most of the spreadsheet out to make for a much quicker crash (w/5.0.4.2).  Recalculate crashes it.  Remove the contents of column $Splits.D and it no longer crashes.  Hopefully this makes it easier to debug.
Comment 12 Julien Nabet 2016-01-31 10:57:05 UTC
Created attachment 122295 [details]
bt part

On pc Debian x86-64 with master sources updated 2 days ago, I could reproduce the crash.
I retrieved a bt but only attached a part.
I wonder if there could be some kind of infinite loop/recursion.
Comment 13 rlk 2016-02-15 16:36:23 UTC
Verified that it still crashes with 5.1.0.
Comment 14 Commit Notification 2016-03-15 16:44:23 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=29ee431c1cf859c3d5a5041cff5cb04b89db27a0

Resolves: tdf#93196 add RecursionCounter guard also to InterpretFormulaGroup()

It will be available in 5.2.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 15 rlk 2016-03-15 17:04:39 UTC
Excellent.  That will let me retest my other issues.  I'd really like to be able to migrate off 4.2.7 finally.
Comment 16 Eike Rathke 2016-03-15 17:16:34 UTC
Pending review
https://gerrit.libreoffice.org/23279 for 5-1
https://gerrit.libreoffice.org/23280 for 5-0
Comment 17 Commit Notification 2016-03-15 19:42:37 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c56e92e4ed1f11de5c89b4a5eda6f91de3053941&h=libreoffice-5-1

Resolves: tdf#93196 add RecursionCounter guard also to InterpretFormulaGroup()

It will be available in 5.1.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 18 Commit Notification 2016-03-15 21:12:09 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b14cc2f16d00c103cf415a54e163d54764d0a86b&h=libreoffice-5-0

Resolves: tdf#93196 add RecursionCounter guard also to InterpretFormulaGroup()

It will be available in 5.0.6.

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 19 rlk 2016-03-17 17:42:51 UTC
Confirmed that this issue is fixed in the latest 5.1 dev build.

I presume these are debug builds?  It's much slower than 4.2.7.