Bug 36746

Summary: Calc systematically aborts when trying to sort on two columns
Product: LibreOffice Reporter: Helmut Leininger <hlein>
Component: CalcAssignee: Kohei Yoshida <kohei>
Status: RESOLVED FIXED    
Severity: normal CC: LibreOffice, vitriol_vitriol
Priority: medium    
Version: 3.4.0 Beta3   
Hardware: Other   
OS: Windows (All)   
Whiteboard: target:3.4
Crash report or crash signature: Regression By:
Attachments: Spreadsheet which produces the error
Spreadsheet that shows the problem

Description Helmut Leininger 2011-05-01 09:39:15 UTC
Created attachment 46226 [details]
Spreadsheet which produces the error

calc always aborts when I try to sort the sheet Grinzing of the attached document on Name and Ref. (Daten - Sortieren - Name and Ref , ascending)

Windows XP Sp3,  LibreOffice 3.4 Beta 3
Comment 1 Helmut Leininger 2011-05-01 09:42:22 UTC
Calc also aborts when trying to sort other sheets, also sortin onlyone column
Comment 2 Markus Mohrhard 2011-05-01 10:43:27 UTC
Assigned to me

Is related to the new sheet local anonymous db data

SIGSEGV in GetAnonymousDBData()

@Helmut: Can you save the Spreadsheet and reopen it after closing Calc?
Comment 3 Helmut Leininger 2011-05-01 10:59:56 UTC
Calc automatically saves the spreadsheet when it aborts. I can reopen it - LibO executes the recovery. I can make modifications to the document, no preoblem. But when I try to sort, it aborts. Once, after some changes, I could sort one sheet, but since the next time, it aborts again.

No problem sorting the same spreadsheet with LibO 3.3.2

Regards
Comment 4 Helmut Leininger 2011-05-02 01:49:07 UTC
Remark:
The problem occurs also in OpenOffice 3.4 beta.
Comment 5 Markus Mohrhard 2011-05-02 02:49:02 UTC
Can you give some additional information when this happens? I think you installed de language pack?

At least with your information that OO3.4 beta crashes too, I can't reproduce this problem.
Comment 6 Helmut Leininger 2011-05-02 03:59:24 UTC
Created attachment 46247 [details]
Spreadsheet that shows the problem
Comment 7 Helmut Leininger 2011-05-02 04:04:37 UTC
OOO:
I have the German language pack installed. The slight difference in the behaviour of OOO and LibO is that OOO restarts aautomatically (LibO must be restarted manually) and it gathers some information that is sent to Oracle.

I made another test after de-installing the language pack - Calc keeps aborting.

The attachment id=46247 (Comment 6, second of the attachments) shows the problem, trying to sort "Grinzing" by "Sortierung" and "Name"
Comment 8 Rainer Bielefeld Retired 2011-05-02 10:42:53 UTC
[Reproducible] with "LibreOffice 3.4Beta3  – WIN7  Home Premium  (64bit) German UI [DEV300m103 (Build:3)]"

Steps to reproduce:
1. Select columns A,B by clicking Column Heading 'A' and then dragging
   Mouse pointer with pushed left mouse button to Heading 'B'
2. Menu 'Data > Sort > A=ascending, B= ascending
   Libo crashes

Attention, it might be that that crash will destroy your LibO, I lost ability to open 1 particular spreadsheet what I had used until that test without problems.

Modified Status due to facts.
Comment 9 Kohei Yoshida 2011-05-03 09:02:30 UTC
Per our email conversation, I'll take a look at this.
Comment 10 Kohei Yoshida 2011-05-03 09:54:52 UTC
Something must have changed in the undo manager in OOo code, which we inherited.  That one is causing the undo object to get deleted as soon as it is added, which causes the crash.
Comment 11 Kohei Yoshida 2011-05-03 13:13:42 UTC
This

http://cgit.freedesktop.org/libreoffice/calc/commit/?h=libreoffice-3-4&id=d53ec5342f018f7c766e47bf67aefebd3fe76d6a

fixes it.

Prior to the change in SfxUndoManager, the undo manager was either enabled or disabled.  After the change, however, SfxUndoManager keeps track of the number of times EnableUndo(true) and EnableUndo(false) have been called, so if you call EnableUndo(false) 10 times, you need to call EnableUndo(true) the same amount of times in order to get it re-enabled.

In Calc, unfortunately we tend to call EnableUndo(false) so many times, just to be safe, and expect it to get re-enabled by calling EnableUndo(true) just once.  This assumption no longer holds true, and as this report demonstrates it sometimes causes crashes.

Anyway, this should now be fixed in the 3.4 branch.