Created attachment 67364 [details] A simple ODS spreadsheet which will cause LO 3.6.1.2 to crash First, a disclaimer: this is very odd behavior that I've tried to pin down to the smallest set of steps that will reproduce the crash. I'm not very good at this, so I apologize if I'm not using the right terminology for "computed cells" (e.g., cells containing a formula based on values from other cells). I have attached the OS X crash reporter output, and a simple ODS file which I believe will reproduce the crash on affected systems (possibly only Mac OS X?). I cannot reproduce this behavior with the 3.6.2.whatever build that is currently available for Mac OS X on libreoffice.org. The bug is also not present on OO 3.4.1. These are the only two other builds/OSes I'm able to compare with at the moment. As a result, I'm guessing this is a very small regression that is probably easy to fix. Symptom: -------- Currently available 3.6.1 download for Mac OS X crashes when performing a deletion operation (delete, Fn + delete, Command + X) on multiple selected cells, when one of the cell's values is based on another cell's value (which is also computed based on other cells' values), IFF the previously-computed cell is the first "argument" to the formula in the second computed cell. Deleting individual cells cells (e.g., Delete or Fn + Delete on Mac) does not cause the crash, only when the operation is performed on a multi-cell selection comprised of a computed cell as described above. Changing the order of arguments in the second computed cell also eliminates the behavior. The crash ONLY occurs when the previously computed cell (the third cell mentioned in the description, containing a forumla) is the FIRST argument to the operation in the fourth cell. E.g. If A3 is computed based on A1 and A2, then a cell formula =A3/A4 will cause the crash, but =A4/A3 will not. Consistently reproducible. Support for assistive devices in the OS X "Universal Access" prefpane is verified disabled (see bug 47368). Steps to reproduce: ------------------- Create a new worksheet. Perform the following steps: - Enter a value into a cell (say, cell A1 to 3) - Enter another value (say, cell A2 to 4) - Compute a third cell based on those two (say, cell A3 to =SUM(A1:A2)) - Compute a fourth cell based on the third cell and some other cell, but put the third cell FIRST in the order of arguments to the computation (e.g., cell A4 to =A3/A2). Make a multi-cell selection with the mouse, to include the FOURTH computed cell (A4 in the example). Then perform an edit operation to remove the cells from the sheet, e.g., delete or cut. Observe the LibreOffice (3.6.1.2, Build ID: e29a214) crashes.
Created attachment 67365 [details] Mac OS X crashdump produced by the crash described in the report Attached Mac OS X crashdump for the described behavior.
Thank you very much for your bug report! REPRODUCIBLE with LibreOffice 3.6.1.2, German langpack installed, on Mac OS X 10.6.8 (Intel), and the reporter’s sample file; the stack trace is exactly the same as in Kevin’s crashdump. But, good news: NOT reproducible with LibreOffice 3.6.2.1, German langpack installed, on the same machine, and the reporter’s sample file. No crash occurs, the contents of all four cells A1-A4 are correctly cleared. So this bug was fixed in the 3.6.2 development process (probably by the fix for bug 53364 or a similar bug). You can confirm this yourself if you download 3.6.2.1 (the current pre-release) from http://www.libreoffice.org/download/pre-releases/ and test the same issue again. (Setting Status to RESOLVED/WORKSFORME, as appropriate in such cases; abbreviating the Summary a bit: the crash was not specific to Mac OS X 10.7.x, because I could reproduce it on 10.6.8.)
I knew this was fixed in the 3.6.2 release candidate before I filed. Should I have reported the bug? I'm not well-versed in the finer points of bug reporting etiquette, but I figured that a reproducible crasher in the currently-shipping version of LO should be noted. I would gratefully receive any feedback (in private email, if you don't want to clutter the bug report) as to how better to handle a situation like this in the future.
(In reply to comment #3) > I knew this was fixed in the 3.6.2 release candidate before I filed. Should I > have reported the bug? > > I'm not well-versed in the finer points of bug reporting etiquette, but I > figured that a reproducible crasher in the currently-shipping version of LO > should be noted. I would gratefully receive any feedback (in private email, if > you don't want to clutter the bug report) as to how better to handle a > situation like this in the future. Oh, sorry! I may have missed your line: “I cannot reproduce this behavior with the 3.6.2.whatever build” when I read your bug report, therefore I did not appreciate this hint as appropriate. About your general question: AFAIK we don’t have a general rule for cases like this. But most LibreOffice bugwranglers will just not take the time to report a bug (even if it is a crasher) in a x.y.1 version when they already know that it will be fixed in the upcoming x.y.2 version which is (thanks to the time-based release train of LibreOffice) only some weeks away. Of course, _very_ critical bugs (like such which make it impossible to install or start LibreOffice at all) should be reported anyway, because it may be necessary to mention them on the download page. But in such extremely critical cases it may be more appropriate to write directly to the developer mailing list <libreoffice@lists.freedesktop.org> or to the QA mailing list <libreoffice-qa@lists.freedesktop.org>, instead of filing a bug ... So, what I want to say: you can report such bugs, if you want, but most people just don’t take the time to do so. (And it will also cost time for a bugwrangler to read, confirm, and answer your bug report.) But this is just my point of view, so feel free to write about this question to the QA mailing list <libreoffice-qa@lists.freedesktop.org> to get a disucssion which will probably result in a more authoritative answer.