Created attachment 101647 [details] Larger spreadsheet, crashes The following procedure crashes on the first spreadsheet (large, taken from bug 80342), but not the second (much smaller). Highlight column A Go to Data -> Sort Ask for the selection to be extended Using default sorting options, specify single sorting key as Column A, ascending Click OK… Interestingly, if I copy e.g. even just the header and the first record in the larger spreadsheet to a new spreadsheet, it still crashes if I attempt to sort. (Note: deemed not a duplicate of bug 80342. I am leaving this as OS X x86-64 exclusive until Laurent BP can confirm again on x86 Windows.)
Created attachment 101648 [details] Example crash report for larger spreadsheet
Created attachment 101651 [details] Smaller spreadsheet, does not crash
Created attachment 101663 [details] Test case with empty second line I can reproduce crash on Win7-x86 LibO Version: 4.3.0.1 Build ID: 67f5430184326974072b65403ef1d9d934fc4481 The bug seems not be linked to the size of the spreadsheet but on the way LibO use to extend selection when second line is empty. I add an empty line to attachment 101648 [details] on line 2, then LibO crash in the same way. Steps to reproduce from scratch: 1. Create a new spreadsheet 2. Type headers in the first line 3. Leave second line empty 4. Add random data such as in attached document 5. Click on column A to select all column 6. Click on "Sort Ascending" button 7. Click on "Extend Selection" => crash Reproduce with LibO 4.2.5.2, 4.3.0.1 and Version: 4.4.0.0.alpha0+ Build ID: 32ac015be4d0f33120bc066e7f49e197c7405c45 TinderBox: Win-x86@39, Branch:master, Time: 2014-06-10_04:54:30 NOT reproduce with LibO 4.1.6.2 and Version: 4.2.1.0.0+ Build ID: 63950ec72806489b41c2109f5c3840dcf22f4c6c I wrongly report no crash with LibO 4.2.5.2 in bug 80342.
Set as new, with version 4.2.5.2. Change title to reflect the role of "extend selection"
(In reply to comment #4) I would rather say that it doesn't crash when the selection is being extended, it crashes when the sort is being performed on the extended selection (since the procedure I describe is the other way around). > Set as new, with version 4.2.5.2. Change title to reflect the role of > "extend selection"
Simpler, faster crash: 1. Open attachment 101663 [details] 2. Select A1:B1 3. Click on "Sort Ascending" button => crash The problem is not linked to the extension of the selection, but to sorting a one row selection. I propose a new title: "Crash when sorting one row selection" In attachment 101647 [details] and attachment 101663 [details], as second line is empty, automatic extension of selection is limited to the first line (even if you selected whole first column: check blue border when LibO ask to extend or not selection).
(In reply to comment #6) > The problem is not linked to the extension of the selection, but to sorting > a one row selection. I propose a new title: "Crash when sorting one row > selection" > That seems to be it. Open new spreadsheet, populate a single row only, click sort, crash. It definitely doesn't have to be a case where selection is extended.
Reproduce with daily master Version: 4.4.0.0.alpha0+ Build ID: 45f18e2ff2a54c412f296818fd73111cb62c7f3d TinderBox: Win-x86@39, Branch:master, Time: 2014-06-24_06:47:18 Select one cell, sort, crash.
NOT reproduce with LibO 4.2.4.2 Reproduce with Version: 4.2.5.0.0+ Build ID: 8ff260e47873674ca03a334f6b3198d66dc68db7 TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-05-04_21:46:54 may be due to other sorting bug such as bug 72741
As there is crash, set severity to critical. Set importance to highest, and promote it as MAB.
(In reply to comment #8) > Reproduce with daily master Version: 4.4.0.0.alpha0+ > Build ID: 45f18e2ff2a54c412f296818fd73111cb62c7f3d > TinderBox: Win-x86@39, Branch:master, Time: 2014-06-24_06:47:18 > > Select one cell, sort, crash. I don't reproduce this on pc Debian x86-64 with master sources updated today. But I reproduced the crash of comment#6.
Created attachment 101695 [details] bt console from master sources Indeed a pb here: #4 0x00002aaac86bd119 in (anonymous namespace)::GetOptimalHeightsInColumn (rCxt=..., pCol=0x2aaadbd2b010, nStartRow=1, nEndRow=0, aHeights=std::__debug::vector of length 0, capacity 0, pProgress=0x0, nProgressStart=0) at /home/julien/compile-libreoffice/libreoffice/sc/source/core/data/table1.cxx:93
*** Bug 80342 has been marked as a duplicate of this bug. ***
Attachment 102097 [details] of bug 80342 contains a crash dump for same bug
taking it.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5902dcf0995cdd0a6c1dbd1f9c21b0b2b3f5609f fdo#80462: Don't always increment the start row position. 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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e5b1eb98b8e97b184f8c6876b154f47b6e0730d fdo#80462: Write test for this. 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.
Fixed.
Requests for 4.2 and 4.3 backports are on gerrit.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee5895488c43954b25b26076ec9241e7c741cffd&h=libreoffice-4-3 fdo#80462: Don't always increment the start row position. It will be available in LibreOffice 4.3.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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f97d25b66e88742e4cb4011cc4cc0bc682c1ee1c&h=libreoffice-4-2 fdo#80462: Don't always increment the start row position. It will be available in LibreOffice 4.2.7. 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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-3-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=628f27b42a5911288e15ae9edf182578dd32a4da&h=libreoffice-4-3-0 fdo#80462: Don't always increment the start row position. It will be available already in LibreOffice 4.3.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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=44b270d2e05ab29d73366c5db3e31750614b7c6e&h=libreoffice-4-2-6 fdo#80462: Don't always increment the start row position. It will be available already in LibreOffice 4.2.6. 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 84991 has been marked as a duplicate of this bug. ***