Description: Not sure if a one-time crash is of value but there's a "signature" attached. Steps to Reproduce: 1. select a range of cells 2. right click and choose format cells crash Actual Results: crash (see screenshot and signature text file) Expected Results: no crash Reproducible: Couldn't Reproduce User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Created attachment 133854 [details] signature
Created attachment 133855 [details] screenshot
Hello kevin, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 133856 [details] as requested I work full time on this one file - it's very big and getting bigger. I usually just paste a few cells to demo a bug into a fresh .ods, but this was a one time crash. I was in the vicinity of row 3200 when the crash occurred. If you want to see how bad my many bug reports are, try looking at the songs before 3200 and trying to make the ones after that look as good as the ones before (especially as pertains to superscript, font changes, bold and underlines within the same cell. You'll see not only how often the problems I've reported come up, but how insane it is for you to add "styles" as a major feature and cripple them by not allowing someone to change the selection for example to bold italic without also having to change the font of every character within the selection. It's a travesty. The whole point of styles is to be able to change some attributes without changing others. It's like building a car and forgetting to add door handles.
Hi Kevin, Thank you for sharing the file. I've tried with different ranges of cells but I could not reproduce the crash. Did you do anything ( copy, paste, undo, format... ) before the crash happened?
> Did you do anything ( copy, paste, undo, format... ) before the crash > happened? I use no formulas - the operations I do are 1. add rows 2. cut and paste ranges of cells 3. change backgrounds, borders, font sizes, superscript, bold and italic 4. type in new information 5. and I use Undo a lot Those are the only operations I do but I do them over and over full time, so when I say the the UI for formatting is extremely buggy and unfriendly, I speak with the weight of hundreds of hours of focused work on just that one area. As for this crash, and stability in general, Calc is surprisingly stable. I've only had about 3 crashes in all this time. What's NOT stable is the ability to retain the formatting changes I've made. Cells suddenly go wacky with whole strings of underlining and superscript that I absolutely never entered. All of this goes back to the UI decision to allow unselected characters to impose their formatting on selected characters when the user types to replace existing text. No one seems to care about these problems - only the crashes get any attention - maybe if I find a way to make the formatting bugs a condition in the steps to create a crash? I get that crashing in general is more important than UI, but this is ridiculous. For every crash I've had, I've spent 100 hours of unnecessary labor working around the UI bugs.
This bug may stay open but I'm afraid it's of no use. Even Needinfo is not appropriate because submitter may have no other info. So I recommend this be closed as Insufficient Data. You may set it back to Unconfirmed should you experience it again. There are some nasty bugs with paste and undo. This may be or not related. Kevin, if there's no Crash Report, and sometimes there's no in Windows, you may use procdump (part of free and useful Sysinternaly Suite) during LO run in order to get a dump (soffice.bin.dmp). How: - run procdump manually after LO start (path-to\SYSINTERNALSSUITE\procdump.exe soffice.bin -h path-to\soffice.bin.dmp) for reproducible bugs like this one, OR - via simple batch file like attachment 129814 [details], that is used instead of LO icon to start LO, for intermittent bugs (which seems to be the case here). You may upload that crash dump or do it yourself: - analyze dump with WinDbg configured per https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg (set "Symbol File Path") - attach here as an attachment result of "!analyze -v" command in WinDbg (that's "backtrace") - if "!analyze -v" is empty, which comes after "ntdll!NtTerminateProcess" error, go with "kb" that prints stack trace and "~* kp" to dump the whole stack.
(In reply to Kevin from comment #6) > As for this crash, and stability in general, Calc is surprisingly stable. > I've only had about 3 crashes in all this time. What's NOT stable is the > ability to retain the formatting changes I've made. Cells suddenly go wacky > with whole strings of underlining and superscript that I absolutely never > entered. All of this goes back to the UI decision to allow unselected > characters to impose their formatting on selected characters when the user > types to replace existing text. No one seems to care about these problems - > only the crashes get any attention - maybe if I find a way to make the > formatting bugs a condition in the steps to create a crash? I get that > crashing in general is more important than UI, but this is ridiculous. For > every crash I've had, I've spent 100 hours of unnecessary labor working > around the UI bugs. I'm not going into this, but did you search for current and closed bugs? Could you formulate this as an reproducible issue? When did this start? Please read https://wiki.documentfoundation.org/QA/BugReport and then you may report.
> Could you formulate this as an reproducible issue? > When did this start? As I explained at the outset, this happened only once and I only reported it because it generated the attached dumps, which apparently aren't enough to help you. Since I reported it almost 2 months ago, I have only had one crash. I had been experimenting with Libre Writer and it crashed both that and Calc at the same time. I'd say two crashes in two months is about 1% as bad as the ongoing torture of the graphic UI and I continue to be appalled that you guys aren't fixing any of the well-researched, well-argued reports I've supplied. I had such high hopes for a non-corporate alternative to Excel, but I'm deeply disappointed in the whole project.
What you reported in Description cannot help, unfortunately, if not reproducible. Signature is also of no help, if you don't get Crash Report. So this needs to be closed. Can be closed as Insufficient Data, but I'll set as a duplicate of Bug 108340. No proof but no harm also. As for other bugs, talk doesn't belong here. If you want to help: https://www.libreoffice.org/community/get-involved/ or http://www.libreoffice.org/donate/ or just wait, it goes like this: https://blog.documentfoundation.org/blog/2017/05/31/libreoffice-quality-assurance-six-months-statistics-part-1/. But you already may know that, since you reported 29 bugs. Thank you. Just please search for duplicated before submitting. You also may: - get http://tdf.io/siguiexe to easily get and run "parallel" LO in Windows (extract without installation) - run different extracted versions (like fresh 5.3.4.2 and 5.4.0 and master 6.0+) and architectures (32-bit or 64-bit) related to a bug in order to test crash In this way you may see when the bug started to see if it's a regression. Even better is bibisection, which brings bug step to solving. *** This bug has been marked as a duplicate of bug 100289 ***