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

Bug #1444110 reported by Chris Hermansen
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice
Fix Released
Critical
libreoffice (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

cd ~/Desktop && wget -c https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1444110/+attachment/4375799/+files/NEWMAST_core_5e_crashed_sort.ods -O example.ods && localc --nologo example.ods

Highlight column U > Data > Sort... > Current selection > OK

ProblemType: Crash
DistroRelease: Ubuntu 15.04
Package: libreoffice-core 1:4.4.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-14.14-generic 3.19.3
Uname: Linux 3.19.0-14-generic x86_64
ApportVersion: 2.17.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 10:58:27 2015
ExecutablePath: /usr/lib/libreoffice/program/soffice.bin
InstallationDate: Installed on 2015-03-29 (15 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Beta amd64 (20150325)
ProcCmdline: /usr/lib/libreoffice/program/soffice.bin --calc file:///tmp/NEWMAST_core_5.xlsx --splash-pipe=5
SegvAnalysis:
 Segfault happened at: 0x7f4eab36f7d3: movzwl (%rax,%rdx,2),%r12d
 PC (0x7f4eab36f7d3) ok
 source "(%rax,%rdx,2)" (0xfffffffffffffffe) not located in a known VMA region (needed readable region)!
 destination "%r12d" ok
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: libreoffice
StacktraceTop:
 ?? () from /usr/lib/libreoffice/program/../program/libsclo.so
 ?? () from /usr/lib/libreoffice/program/../program/libsclo.so
 ScDocShell::AdjustRowHeight(int, int, short) () from /usr/lib/libreoffice/program/../program/libsclo.so
 ScDBDocFunc::Sort(short, ScSortParam const&, bool, bool, bool) () from /usr/lib/libreoffice/program/../program/libsclo.so
 ?? () from /usr/lib/libreoffice/program/../program/libsclo.so
Title: soffice.bin crashed with SIGSEGV in ScDocShell::AdjustRowHeight()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

Revision history for this message
Chris Hermansen (c-hermansen) wrote :
information type: Private → Public
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceTop.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in libreoffice (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
penalvch (penalvch)
Changed in libreoffice (Ubuntu):
status: New → Incomplete
Revision history for this message
Chris Hermansen (c-hermansen) wrote :

Christopher Penalver, nice to "talk" with you again. Hope you are well.

Attachment requested included.

Revision history for this message
Chris Hermansen (c-hermansen) wrote :

Good morning, Christopher Penalver,

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.

Revision history for this message
penalvch (penalvch) wrote :

Chris Hermansen, the issue you are reporting is an upstream one. Could you please send the bug to the developers of the software by following the instructions verbatim at http://wiki.documentfoundation.org/BugReport ? When you have done so, please provide a direct link, so that a bugwatch may be added that will inform us about the status. Thanks in advance.

description: updated
Changed in libreoffice (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
In , Chris Hermansen (c-hermansen) wrote :

Created attachment 114971
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.

Revision history for this message
Chris Hermansen (c-hermansen) wrote :

Christopher Penalver, here is the Bugzilla link

https://bugs.documentfoundation.org/show_bug.cgi?id=90757

Revision history for this message
In , julien2412 (serval2412-6) wrote :

Created attachment 114997
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

Changed in df-libreoffice:
importance: Unknown → Critical
status: Unknown → Confirmed
Revision history for this message
In , Fdbugs-a (fdbugs-a) wrote :

This began at the below commit.
Adding Cc: to <email address hidden>; Could you possibly take a look at this one? Thanks

    commit 9a568c41ccd1ccf6073758973da5914a44f629d2
    Author: Eike Rathke <email address hidden>
    AuthorDate: Fri Dec 5 21:32:06 2014 +0100
    Commit: Eike Rathke <email address hidden>
    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

Revision history for this message
In , Eike Rathke (erack) wrote :

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.

Revision history for this message
In , Chris Hermansen (c-hermansen) wrote :

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!

Revision history for this message
In , Mariosv (mariosv) wrote :

*** Bug 91024 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Fdbugs-a (fdbugs-a) wrote :

(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)

Revision history for this message
In , Eike Rathke (erack) wrote :

@Chris:
I did what you described, sorting only on entire selected column U.

Revision history for this message
In , Eike Rathke (erack) wrote :

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.

Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

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.

Revision history for this message
In , Eike Rathke (erack) wrote :
Changed in df-libreoffice:
status: Confirmed → Fix Released
Revision history for this message
In , Chris Hermansen (c-hermansen) wrote :

(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.

Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

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.

Revision history for this message
In , Mariosv (mariosv) wrote :

*** Bug 91290 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Qubit (qubit) wrote :

Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]

Revision history for this message
penalvch (penalvch) wrote :

Fixed in Xenial.

Changed in libreoffice (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.