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 (retired, only occasionally showing up)
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 (retired, only occasionally showing up) 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.