Description: Calc crashes when I enter a unicode code point. Steps to Reproduce: 1. Focus cursor on a cell 2. Press Ctrl+Shft+U+00d7 to enter × 3. Press return or space to complete entering the unicode code point (tab does not work at all) Actual Results: At this point, calc crashes with 100% reliability. It does not matter if there is any other text or numbers in the cell. Expected Results: Cell shows × and cursor is still focused on cell so that I can continue typing something else after the × Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
Also, I don't feel that my browser information is relevant to the bug or the rest of the world. I can see that prior to filing the bug that "All your contributions to this Bugzilla, including your e-mail address and other personal data contained in your bug report, will be publicly available and cannot be deleted." but at no point do I get told that my browser information will be added to the bug.
(In reply to Kat from comment #1) > Also, I don't feel that my browser information is relevant to the bug or the > rest of the world. I can see that prior to filing the bug that "All your > contributions to this Bugzilla, including your e-mail address and other > personal data contained in your bug report, will be publicly available and > cannot be deleted." but at no point do I get told that my browser > information will be added to the bug. Good point, we will get rid of it as it's not really useful anymore... Thanks for pinpointing it
I can't reproduce the crash in Version: 6.0.4.2 Build ID: 1:6.0.4~rc2-0ubuntu0.16.04.1 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
No crash here either. Please copy and paste here the contents of your Help - About. This allows us to know more about your system. Arch Linux 64-bit Version: 6.0.4.2 Build ID: 6.0.4-1 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group
Version: 6.0.4.2 Build ID: 6.0.4-2 CPU threads: 4; OS: Linux 4.16; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group Reset profile (which in itself seems to be broken, or the wiki page could be imprecise/wrong), but it's still crashing for me 100% of the time both in safe mode and normal mode.
If you are using a distribution such as Ubuntu, you might get a backtrace of the crash after installing debug symbol packages: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information
I can not reproduce the bug in: Version: 6.1.0.0.beta1 Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; and Version: 6.0.5.1 Build ID: 0588a1cb9a40c4a6a029e1d442a2b9767d612751 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; no crash, working as expected.
The Ctrl+Shift+U[unicodepoint] is a gtk+ control (see GtkIMContext), is there an input method conflict with the gtk3? Otherwise as implemented for bug 73691 LibreOffice's default cross platform entry method for the Unicode string toggle is <left alt>+x, That is 1. focus in cell 2. type U+00d7 leaving cursor at end of string entry 3. type <left alt>+x a second <left-alt>+x will toggle back to the input string. Any glyph in text can be toggled in all LO modules. Some adjustments of the <left alt>+x toggle were made for keyboard needs of several locales <left alt>+c to toggle, and macOS required a different three key -- CMD+Option+x (aka X_MOD1_MOD2) toggle. Does <left-alt>+x toggle crash?
On pc Debian x86-64 with master sources updated today, I don't reproduce the crash. I just noticed these kind of logs on console: warn:svx:19691:19691:svx/source/accessibility/AccessibleTextHelper.cxx:1403: DBG_UNHANDLED_EXCEPTION in virtual void accessibility::AccessibleTextHelper_Impl::Notify(SfxBroadcaster&, const SfxHint&) type: com.sun.star.uno.RuntimeException message: Text forwarder is invalid, model might be dead context: ScAccessibleEditObject Do you use accessibility tools or did you enable some of them? (eg: Orca)
(In reply to V Stuart Foote from comment #8) > The Ctrl+Shift+U[unicodepoint] is a gtk+ control (see GtkIMContext), is > there an input method conflict with the gtk3? FWIW, I don't have any problems with this in any other application that I've tried (e.g. web browser, text editor, terminal, inkscape, pidgin and so on) so I don't think it would be an input method conflict. Is there anything I can do to test? > […] > > Does <left-alt>+x toggle crash? Yes, this works as a temporary solution… thanks!
(In reply to Kat from comment #10) > FWIW, I don't have any problems with this in any other application that I've > tried (e.g. web browser, text editor, terminal, inkscape, pidgin and so on) > so I don't think it would be an input method conflict. Is there anything I > can do to test? Could you try getting the backtrace of the crash? Steps are here: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace
Created attachment 142867 [details] backtrace
Thanks, Kat! So it has something to do with GTK3, no idea what else it could depend on.
*** This bug has been marked as a duplicate of bug 116951 ***