Summary: | EDITING Calc crash sort | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Chris Hermansen <clhermansen> |
Component: | Calc | Assignee: | Eike Rathke <erack> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | brian.phillip.ward, chris, erack, fdbugs, jmadero.dev, serval2412, wss9062 |
Priority: | highest | Keywords: | bibisected, bisected, haveBacktrace, regression |
Version: | 4.4.2.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: | https://launchpad.net/bugs/1444110 | ||
Whiteboard: | target:5.0.0 target:4.4.4 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 79641 | ||
Attachments: |
This is the file described above that causes the crash
bt with debug symbols |
Description
Chris Hermansen
2015-04-20 23:49:07 UTC
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] |