Bug Hunting Session
Bug 86305 - EDITING: Entering data into a cell changes array formula that references that cell
Summary: EDITING: Entering data into a cell changes array formula that references that...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: highest major
Assignee: Eike Rathke
URL:
Whiteboard: target:5.1.0 target:5.0.0.1 target:4.4.5
Keywords: bibisected, bisected, regression
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2014-11-15 03:52 UTC by J David Eisenberg
Modified: 2016-10-25 19:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
File with an array formula that changes when one of its dependent cells changes. (17.69 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-11-15 03:52 UTC, J David Eisenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description J David Eisenberg 2014-11-15 03:52:32 UTC
Created attachment 109500 [details]
File with an array formula that changes when one of its dependent cells changes.

In the attached spreadsheet, cell B7 contains the array formula:
{=IF(SUM(B2:B4) > 0, SUM(B2:B4*D2:D4/C2:C4), 0)}

Enter the number 50 into cell B3; cell B7 correctly updates to 17.5%. Now look at the formula in cell B7. It has changed to:
{=IF(SUM(B2:B4) > 0, SUM(B2:B4*D2:D4/C2:C4), 0.175)}

If you go to cell B3 and press the delete key, the result in cell B7 remains unchanged instead of going back to zero.

A similar file imported from XLSX format works correctly.
Comment 1 Joel Madero 2014-11-16 20:59:40 UTC
Confirmed - and bibisected.

Ubuntu 14.10 x64
LibreOffice 4.3.2.2 release

New
Major - loss of data
Highest - MAB - regression + formula change that is really unknown until you try subsequent changes.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ec7e48ec3d7f601df54ad762a616690ead24a76d is the first bad commit
commit ec7e48ec3d7f601df54ad762a616690ead24a76d
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sun May 11 22:03:42 2014 +0000

    source-hash-3f0a8dc3c8204d6a500a5da64ad57996d593022f
    
    commit 3f0a8dc3c8204d6a500a5da64ad57996d593022f
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Sun Mar 9 17:06:59 2014 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Sun Mar 9 17:06:59 2014 +0000
    
        coverity#707905 Uninitialized scalar field
    
        Change-Id: Icb00858146d65963a1c3144a61aa467d7da461e4

:100644 100644 54455f758aefb064323f234efba185f166c2f5e7 0c2b4dfe8e947c5f3a92e59ddf9bfa5942d1638d M	ccache.log
:100644 100644 34ccfab90a686f9580f31e9a5ac4956c3a0bf1c2 ccd34f584d111c786b0a501f36a293d14f4c1f06 M	commitmsg
:100644 100644 6113187fae89735d22d041cd095a0723d3fe4c32 a7923a2d4a14ba7c495f817b0fb83e3594ec2bc7 M	make.log
:040000 040000 bad2d9449e94407aef0cf701999b6a5bbee96b05 9ed00b62d470359016b968190db4cd858bc36922 M	opt
Comment 2 Matthew Francis 2014-12-24 11:44:41 UTC
(Commented as part of a sweep of bugs that are bibisected but not source bisected)

Building the source in the bibisect range unfortunately does not appear to give a working binary.

Looking only at changes in the range which affect sc/ , it seems likely that one of these three is the cause:

commit 3cea6bb57757ce085f01f0b86b000cfc0592dca7
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Sat Mar 8 17:40:32 2014 -0500

    More consistent number format inheritence policy.
    
    The new policy is to always inherit number format of a formula cell
    from its reference unless the cell already has an explicit number format
    set.
    
    Also to avoid recalculating formula cells on load just because they have
    the 'General' number format.  This leads to excessive re-calculation of
    formula cells upon load even when the cells already have results cached.
    
    Change-Id: I28128d3fef296e09e62bea72e8aab75de9876239

commit 5d2e7cbf6433ecced0ecac46b3abdaf97b82880b
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Sat Mar 8 16:27:32 2014 -0500

    This test file had wrong cached formula result stored.
    
    It didn't get flagged before because we would always recalc all formula cells
    with 'General' number format on load...
    
    Change-Id: I36e71534b65f3f088415cd518af04696892f76dd

commit 1c27b0a4fafc525ed704f4348d5f214b5ef2a764
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Sat Mar 8 13:23:12 2014 -0500

    Reduce indentation by early bail-out.
    
    Change-Id: Iaac628d2629bf1ff96fd1709e358ae9eed3fca02
Comment 3 Matthew Francis 2015-01-18 13:44:05 UTC
Better luck building a working binary the second try (probably managed to break my user profile the first time with too much jumping around in history).

It looks like this was the commit that changed the behaviour.

commit 3cea6bb57757ce085f01f0b86b000cfc0592dca7
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Sat Mar 8 17:40:32 2014 -0500

    More consistent number format inheritence policy.
Comment 4 Eike Rathke 2015-06-16 20:16:28 UTC
I'm taking this.
Comment 5 Commit Notification 2015-06-16 22:11:42 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#86305 clone upper left of matrix result if double token

It will be available in 5.1.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 6 Eike Rathke 2015-06-16 22:13:43 UTC
All commits mentioned above are unrelated.
Comment 7 Commit Notification 2015-06-16 22:59:43 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=ab6be8b2b01f9657f105d5ec9b027c9fa99d4325&h=libreoffice-5-0

Resolves: tdf#86305 clone upper left of matrix result if double token

It will be available in 5.0.0.1.

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 8 Eike Rathke 2015-06-16 23:50:08 UTC
Pending review for 4-4 https://gerrit.libreoffice.org/16326
Comment 9 Commit Notification 2015-06-17 13:11:01 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c14d9f721554937577496b448fd685b8b68580c0&h=libreoffice-4-4

Resolves: tdf#86305 clone upper left of matrix result if double token

It will be available in 4.4.5.

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 10 Robinson Tryon (qubit) 2015-12-17 08:39:17 UTC Comment hidden (obsolete)