Created attachment 70488 [details] Testfile to demonstrate behaviour Problem description: Calc sorts columns the wrong way Steps to reproduce: There is an error in sorting columns in calc. How to test: Create a spread sheet similar to this C A D B F E R1 a d R2 b e R3 c f Mark the columns labled C, A...E Sort the columns ascending Expected behavior: A B C D E F R1 a d R2 b e R3 c f Current behavior: C A D B F E R1 c f R2 a d R3 b e Platform (if different from the browser): Macbook Pro 6,2, Ubuntu 12.10 Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0
This does not happen in Calc 3.5.4.2
Confirmed in 4.0-master, though the result is ADCBFE.
Can you please test with 3.6.4.1 or 3.6.4.2 because they should be fixed there.
@Markus Mohrhard: I'd love to whenever the update is downstreamed into Ubuntu repositories. Q: How can such a regression happen? Any ideas or explanations?
(In reply to comment #4) > @Markus Mohrhard: > I'd love to whenever the update is downstreamed into Ubuntu repositories. > > Q: How can such a regression happen? Any ideas or explanations? Calc has about 1 million lines of own source code + several more million lines of shared source code. And how much time did you spend yourself testing master to check for regressions. Marking as fixed as I think it is fixed in 3.6.4.1 and therefore in the 3.6.4 release. Reopen if it is not fixed there.
Reproducible in: Microsoft Windows Vista Business x86 6.0.6002 Service Pack 2 Build 6002 Version 3.6.4.1 (Build ID: a9a0717)
(In reply to comment #5) > (In reply to comment #4) > > @Markus Mohrhard: > > I'd love to whenever the update is downstreamed into Ubuntu repositories. > > > > Q: How can such a regression happen? Any ideas or explanations? > > Calc has about 1 million lines of own source code + several more million > lines of shared source code. And how much time did you spend yourself > testing master to check for regressions. > > Marking as fixed as I think it is fixed in 3.6.4.1 and therefore in the > 3.6.4 release. Reopen if it is not fixed there. First I am pretty sure that not all of the 1 million lines deal with sorting. Second, in my development projects we used test suites to prevent from regression and third there are statistical methods to identify areas of unstable code based on previous bug reports. Assuming that all this is in place here as well, I was wondering what could be the cause of those regressions. If you had an idea I could direct some research effort into how this can be improved. Maybe we can discuss this on a different channel (mail?)
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > @Markus Mohrhard: > > > I'd love to whenever the update is downstreamed into Ubuntu repositories. > > > > > > Q: How can such a regression happen? Any ideas or explanations? > > > > Calc has about 1 million lines of own source code + several more million > > lines of shared source code. And how much time did you spend yourself > > testing master to check for regressions. > > > > Marking as fixed as I think it is fixed in 3.6.4.1 and therefore in the > > 3.6.4 release. Reopen if it is not fixed there. > > First I am pretty sure that not all of the 1 million lines deal with > sorting. Second, in my development projects we used test suites to prevent > from regression and third there are statistical methods to identify areas of > unstable code based on previous bug reports. We have highly coupled code with to less test code. Sadly our code is so old and written by so many people that even simple tasks like sorting affect more places than it should. For example sorting is highly integrated into calc core in ScTable so that a change to fix another bug can introduce a new one in parts that nobody expects. We are writing new tests for fixed bugs but since we are mainly only three developers doing all the work on calc this means that there are thousand of untested cases. However we are always happy if someone helps us out with extending the test cases which is actually not that difficult. > > Assuming that all this is in place here as well, I was wondering what could > be the cause of those regressions. If you had an idea I could direct some > research effort into how this can be improved. Maybe we can discuss this on > a different channel (mail?) We were removing some limitations for sorting in 3.6 and therefore had to change some internal data structure and change the UI code. This was done by a volunteer and sadly not enough tests were written at the time. I would be very glad if you would be intersted in helping with that.
Hello Markus I tried the same sorting on a version 3.6.4.3 downloaded from the web site and installed on a plain machine. The sorting does not work here either. Colums are sorted: ADCBFE I did not have the chance to get a look into the sources. So I'm afraid I'm of little help here.
I was trying to sort columns in ascending/descending order by the row of totals at the bottom of the columns. I'm not sure what order LibreOffice 3.6.4.3 is sorting but it's certainly not numerical. OpenOffice.org works fine for this. I currently have 3.3.0 installed because of an unrelated bug in 3.4.1. This issue apparently goes back at least as far as LibreOffice 3.6.0.2. - see http://ask.libreoffice.org/en/question/5898/libreoffice-calc-sorts-numerical-data-as-text/ LibreOffice sorts vertically just fine. I'm on Windows 7 Home Premium (64 bit).
I'v tried LOdev 4.0. The same problem applies there as well. However, resorting immediately after the first sort produces the correct results.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7af886d7784b321e6cda2a870b514607e355b112 reset one of the sort containers before refilling, fdo#57465 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.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=baa9a119dabfc5e5dbb5c174cebf8c24298bad67&h=libreoffice-4-0 reset one of the sort containers before refilling, fdo#57465 It will be available in LibreOffice 4.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.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3f7589fb540072f3a2434f6de99fe2472dad3b1&h=libreoffice-3-6 reset one of the sort containers before refilling, fdo#57465 It will be available in LibreOffice 3.6.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.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-6-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=238f6797e47a5029ad8bd5df3dfc36bbeff6532c&h=libreoffice-3-6-5 reset one of the sort containers before refilling, fdo#57465 It will be available already in LibreOffice 3.6.5. 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.
As part of regular FDO cleanup we are checking the version of regressions to see if it's the oldest version that displays the incorrect behavior. In this case I have been able to verify the bug existence in Version 3.6.0.0.beta1 (Build ID: 1f1cdd) Changing version to reflect this
*** Bug 57797 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fd745457be6371794ca8178631ecb3523c9474cd tdf#57465: sc: Add UItest It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.