Created attachment 141475 [details] The file which which causes the crash. This bug was filed from the crash reporting server and is br-42e0542a-7a05-42c3-9f12-aef321750f23. ========================================= I have a document, which was created with LibreOffice Calc 6.0.2.1 (x64) at Windows 10. It can be opened and the second table gets displayed. Then I do a simple click on a table cell (for example E120) and LibreOffice Calc crashes immediately, and the document recovery is displayed instead. So far, I can repeat this crash over and over again on my system, as long as I do not recover the document. I'll attach the example file to this report. Version: 6.0.2.1 (x64) Build-ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU-Threads: 6; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL
Reproduced in Version: 6.1.0.0.alpha0+ Build ID: b07e8a7e16ba69e822a309ec280d1987f90021a3 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and back to LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Created attachment 141476 [details] gdb backtrace
@Eike, I thought you might be interested in this one...
Taking.
There's an odd constellation of view settings regarding split/frozen ranges that makes things point into a non-existing range. This can be fixed when reading the document. @Manuel: Do you by chance remember how you created the frozen row on sheet "new", was it a different one before, or columns and rows frozen and then removed, or which menu entry you used and where the cell cursor was positioned then? That would be very helpful to find the place where the bad setting originated from.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=646e9564007b13bd841d28e7c02c060d2f96fb39 Resolves: tdf#117093 sanitize the active grid window value It will be available in 6.1.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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c07193cec5e09d50b20bc5b107da02a7d8f05a5 Related: tdf#117093 place assert on SanitizeWhichActive() results It will be available in 6.1.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.
@Eike: I don't know for sure how I did freeze the row, so the following is more a vague reconstruction of what I probably did. But nothing is for sure. First, it is very likely that before I used that "freeze first row" I first had used the split window function by grabbing this split marker directly above the right scroll bar, and pulling it downwards. I always used this way when I was working with huge tables in previous LibreOffice versions. I believe that later, because of the way an other very famous spreadsheet program which I use at my workplace is doing it, I was than looking for the "freeze rows/columns" function. This document is actually the first time that I use "freeze rows" with LibreOffice. I don't know if I undid the split window before using the freeze, or not. When writing this comment, I just had a look at the interface and I found only two ways to do freeze the row. I am quite sure I did not use the toolbar icon with the dropdown. Therefore, I am somewhat sure that I used (German interface): menu "Ansicht" -> submenu "Zellen fixieren" -> entry "erste Zeile fixieren" In English it is probably called: menu "View" -> submenu "freeze cells" -> entry "freeze first row" Unfortunately I don't remember anymore, whether I deleted the fixed row. In general I am the kind of guy who very often adds/deletes/moves rows/columns and for example I am quite sure that I added the first column (or moved it to that place) at a later point in time and I added the second column even later. On the one hand it is absolutely possible, that I deleted the first row after using the freeze row function. It could be that this first row originally was either an empty row or that I had double column headers in the first and second row. By double column header I mean the first row was used for grouping a few columns (with groups like "Pearls" and "Jewels" ), and second row for describing the column data within each group (like "amount" and "got it"), and data was starting at the third row. I remember that at some point in time I realized that LibreOffice has a limitation of only being able to freeze one single row instead of several rows (unlike in some other very famous spreadsheet program). I believe this was the reason why I changed it to a one line header, using text wrap. It could even be that I had both one empty row or a few empty rows and then after this two rows for such a double header. But on the other hand I am really not sure if I did such a thing and it could also be, that I did never change the first row by removing or adding a row. I absolutely have no idea where the cell cursor was positioned, but there is a good chance that I positioned it like you need to do it in that other very famous spreadsheet program, which would be in the first column, and one row below my own column headers, which is the first data cell. Sorry, that I can't remember more clearly. One thing I forgot to mention, but I don't know if it is related or a completely separate topic: The document was created over days only by using LibreOffice. During the creation I was using a lot of ALT+TAB in Windows 10 for switching between a 3D game and LibreOffice. I often had the problem that at some point in time the keyboard binding in LibreOffice seemed to change. The normal arrow keys (up/down/left/right) did no longer move the cursor from cell to cell. Instead they where scrolling the document, in the same way as it does when you click on the arrow keys at the end of scroll bars. I looked up the key binding in the settings, but the up/down/left/right keys were defined as usual. I might have overlooked it, but in those settings I did not even found a command to scroll the document into a certain direction, which you would be able to assign to a key. And also there doesn't seem to be a combination with ALT/SHIFT/CTRL which does such a scrolling. I usually ignored the problem, and the next day (when Windows was shut down and restarted) it was OK. But it occurred very often within a few days before and after my discovery of the crash described in this bug report. I am still working with the repaired version of the document quite regularly, but then at some day this scrolling issue did never occur again.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3de630074d69517d97c4dc874ad74203d7699e88&h=libreoffice-6-0 Resolves: tdf#117093 sanitize the active grid window value It will be available in 6.0.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.
Thanks for the explanation, alas, I couldn't reproduce the odd values yet. Anyway, this > at some point in time the keyboard binding in LibreOffice seemed to > change. The normal arrow keys (up/down/left/right) did no longer move > the cursor from cell to cell. Instead they where scrolling the > document, in the same way as it does when you click on the arrow keys > at the end of scroll bars is not related, that is the behaviour if the ScrollLock key is activated (same as in Excel).
Verified in Version: 6.1.0.0.beta1+ Build ID: da49f4aeb8d5e9a7d2cba8855d911e7cc1d2f1e2 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Eike, Thanks for fixing this!!