Download it now!
Bug 90757 - EDITING Calc crash sort
Summary: EDITING Calc crash sort
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: highest critical
Assignee: Eike Rathke
URL:
Whiteboard: target:5.0.0 target:4.4.4
Keywords: bibisected, bisected, haveBacktrace, regression
: 91290 (view as bug list)
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2015-04-20 23:49 UTC by Chris Hermansen
Modified: 2015-12-17 08:55 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
This is the file described above that causes the crash (2.42 MB, application/vnd.oasis.opendocument.spreadsheet)
2015-04-20 23:49 UTC, Chris Hermansen
Details
bt with debug symbols (8.11 KB, text/plain)
2015-04-21 21:41 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hermansen 2015-04-20 23:49:07 UTC
Created attachment 114971 [details]
This is the file described above that causes the crash

Bug originally filed on http://launchpad.net as

https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1444110

Where it is described by apport as

soffice.bin crashed with SIGSEGV in ScDocShell::AdjustRowHeight()

I was asked by Ubuntu bug squad to file an upstream bug report.

Here are instructions on how to reproduce the crash

I just confirmed that I can cause this problem at will. Here are the steps:

Open Libre Office Calc.

Select the file I included, NEWMAST_core_5e_crashed_sort.ods, from Recent Documents

    File>Recent Documents>NEWMAST_core_5e_crashed_sort.ods

The file appears to open just fine.

Select column U by clicking in the U column header; in the status panel at the bottom of Libre Calc you should see

    Selected 1048576 rows, 1 column

Sort the column itself

    Data>Sort...

Up comes a panel that suggests you can extend the selection or use the current selection. Click "Current Selection".

Up comes a panel that offers various sorting options; leave as is and click "Ok".

Libre Calc crashes. This can be confirmed by restarting Libre Calc which offers to recover from a crash on that document, and it recovers successfully.

Apport is automatically triggered which filed this bug report in the first instance.

Note that normally one would want to sort the entire sheet by one or more columns, but in this application I am just sorting the column to look for non-blank data and I will Undo the sort subsequently.
Comment 1 Julien Nabet 2015-04-21 21:41:35 UTC
Created attachment 114997 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 2 Matthew Francis 2015-04-22 02:45:54 UTC
This began at the below commit.
Adding Cc: to erack@redhat.com; Could you possibly take a look at this one? Thanks

    commit 9a568c41ccd1ccf6073758973da5914a44f629d2
    Author:     Eike Rathke <erack@redhat.com>
    AuthorDate: Fri Dec 5 21:32:06 2014 +0100
    Commit:     Eike Rathke <erack@redhat.com>
    CommitDate: Fri Dec 5 21:40:27 2014 +0100
    
        Ctrl+A and Data Sort took ages to broadcast ALL cells
    
        ... now that also empty cells are to be broadcasted.
    
        Set dirty and broadcast only the effective data range as determined by Sort.
    
        This is more a workaround, a cleaner solution would be to refactor the
        SetDirty() algorithm to iterate only through broadcasters and use
        AreaBroadcast() to notify area listeners.
    
        However, this can also be easily backported to 4-3.
    
        Change-Id: I6d68ca0088cec6a8328a3e93364ac928ef69babe
Comment 3 Eike Rathke 2015-04-30 16:26:04 UTC
I tried on Fedora 21 with master dbgutil build and current 4-4 (to be 4.4.4) and 4.4.3, but could not reproduce.

@Matthew:
How did you determine that commit? Did you really bisect, or actually bibisect?

However, this
#7  0x00002aaaca38082f in ScDocShell::AdjustRowHeight (this=0x29cc960, nStartRow=1, nEndRow=0, nTab=0)
    at /home/julien/compile-libreoffice/libreoffice/sc/source/ui/docshell/docsh5.cxx:373

looks suspicious with nStartRow > nEndRow, which is propagated down to the other functions on the stack.
Comment 4 Chris Hermansen 2015-04-30 18:11:12 UTC
Hi Eike,

I'm the person who reported the bug.

Would you be so kind as to confirm that when you say "I tried on Fedora 21 with master dbgutil build and current 4-4 (to be 4.4.4) and 4.4.3, but could not reproduce" you mean using the file I uploaded and sorted only on column U?

The reason I ask is that when I originally reported this on Launchpad, the person triaging bugs could not reproduce it until I sent the actual data and instructions.

Thanks very much!  And my apologies in advance if this is a dumb question!
Comment 5 m.a.riosv 2015-05-02 18:42:48 UTC
*** Bug 91024 has been marked as a duplicate of this bug. ***
Comment 6 Matthew Francis 2015-05-04 03:33:00 UTC
(In reply to Eike Rathke from comment #3)
> I tried on Fedora 21 with master dbgutil build and current 4-4 (to be 4.4.4)
> and 4.4.3, but could not reproduce.
> 
> @Matthew:
> How did you determine that commit? Did you really bisect, or actually
> bibisect?

Actually bisected (well, used a pre-release 1:1 bibisect tree for 5.0 master, but same thing ;)

It still crashes for me on master as of 98436c4b53639d86f261ac630c46d32e3c7b8e28 (2015-05-04)
Comment 7 Eike Rathke 2015-05-04 16:04:26 UTC
@Chris:
I did what you described, sorting only on entire selected column U.
Comment 8 Eike Rathke 2015-05-04 17:26:33 UTC
This makes no sense, ScDocShell::AdjustRowHeight() is not even executed from ScDBDocFunc::Sort() in this constellation because the previous call to ScDocument::HasUniformRowHeight() in ScDBDocFunc::Sort() determined all heights are uniform in the range (bUniformRowHeight=true).

However, I know what could go wrong if it actually was executed.. and indeed, when resizing one row (e.g. 3) before the sort I can reproduce.
Comment 9 Commit Notification 2015-05-04 18:57:56 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

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

Resolves tdf#90757 ensure start row / end row order makes sense

It will be available in 5.0.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 10 Eike Rathke 2015-05-04 19:16:05 UTC
Pending review for 4-4 https://gerrit.libreoffice.org/15631
Comment 11 Chris Hermansen 2015-05-05 21:41:34 UTC
(In reply to Eike Rathke from comment #7)
> @Chris:
> I did what you described, sorting only on entire selected column U.

Thanks, @Eike.  I look forward to testing the patch.
Comment 12 Commit Notification 2015-05-07 14:07:38 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=88ea6b734a2a87a41196370cc1d66476e2a19514&h=libreoffice-4-4

Resolves tdf#90757 ensure start row / end row order makes sense

It will be available in 4.4.4.

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 m.a.riosv 2015-05-14 22:25:30 UTC
*** Bug 91290 has been marked as a duplicate of this bug. ***
Comment 14 Robinson Tryon (qubit) 2015-12-17 08:55:11 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]