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.
Created attachment 114997 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
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
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.
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!
*** Bug 91024 has been marked as a duplicate of this bug. ***
(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)
@Chris: I did what you described, sorting only on entire selected column U.
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.
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.
Pending review for 4-4 https://gerrit.libreoffice.org/15631
(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.
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.
*** Bug 91290 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]