Bug 82115 - Repeatable crash/hang entering Japanese into a Writer comment on OSX ( see comment 4 )
Summary: Repeatable crash/hang entering Japanese into a Writer comment on OSX ( see co...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other macOS (All)
: medium critical
Assignee: Not Assigned
Keywords: haveBacktrace
Depends on:
Blocks: CJK CJK-Japanese
  Show dependency treegraph
Reported: 2014-08-04 04:17 UTC by Matthew Francis
Modified: 2022-05-04 03:50 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:
Regression By:

Core dump from the crash (80.94 KB, text/plain)
2014-08-04 04:17 UTC, Matthew Francis
video (1.89 MB, video/mp4)
2014-08-11 06:49 UTC, retired
Updated backtrace (8.05 KB, text/plain)
2014-08-11 10:21 UTC, Matthew Francis
bt with symbols (11.38 KB, text/rtf)
2016-06-26 09:36 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-08-04 04:17:13 UTC
Created attachment 103972 [details]
Core dump from the crash

On OSX 10.9.4 / LO release:

Steps to reproduce:
1. Create a new Writer document
2. Insert a comment
3. Within the comment, start typing any Japanese text with the 'Kotoeri' - 'Hiragana' input method. For instance, 'aaaaaaaaaaaaaaaaa' (which will produce the text 'ああああああああああああああ')
4. Without confirming the input conversion (i.e. without pressing 'Return'), select a new font from the font dropdown
5. Either a crash will occur at this point (see attached backtrace), or a hang when the next Japanese text is input

This appears to be specific to comments - I have not observed the same crash occuring in the body of the document
Comment 1 Matthew Francis 2014-08-04 04:41:32 UTC
Additional note:

When the above results in a hang rather than a crash (i.e. when the font selection is initially successful rather than crashing immediately), I notice that the text that is being entered is deselected, indicating that the input conversion has been aborted

When doing the same thing in the main document text, the text remains selected, and the conversion is not aborted, so the font can be changed in mid entry. This should also be possible in a comment

* I've just spotted a coincidental but probably(?) unrelated issue; in the main document, when changing the font while a Japanese input conversion is open, the font is correctly applied to the whole text of the input, but *only when the next character is entered*. Raised separately as bug 82116
Comment 2 Yousuf Philips (jay) (retired) 2014-08-05 05:46:05 UTC
Hi Matthew,

Thanks for this new bug and crash report. Adding the Mac QA team to confirm.
Comment 3 retired 2014-08-05 09:35:26 UTC
Hi, to reproduce I'd need to know how to "start typing any Japanese text with the 'Kotoeri' - 'Hiragana' input method". Sorry I've not once in my life used those method - whatever they may be.
Comment 4 Matthew Francis 2014-08-05 11:04:24 UTC
(In reply to comment #3)
> Hi, to reproduce I'd need to know how to "start typing any Japanese text
> with the 'Kotoeri' - 'Hiragana' input method". Sorry I've not once in my
> life used those method - whatever they may be.

In OSX 10.9 it's like this: (earlier OSX may be slightly different)

1. Open "System Preferences" from the Apple menu
2. Select "Keyboard"
3. Select the "Input Sources" tab at the top of "Keyboard"
4. Click on the "+" button at the bottom left to add a new input source
5. Select "Japanese" on the left, then "Kotoeri" on the right and click on "Add"
6. Back in the "Keyboard" - "Input Sources" tab, make sure that at least "Input modes:" "Hiragana" is enabled in the Kotoeri options (this should be enabled by default)
7. At the bottom of "Keyboard" - "Input Sources", make sure that "Show Input menu in menu bar" is enabled (again, probably enabled by default)

To test:
1. Open a Writer document
2. With the writer document focused, open the input menu, which is an icon somewhere on the right side of the system menu bar, and select the option that looks like "あ Hiragana"
3. Type some "aaa"s, which should appear as "あああ"

At this point, you should be pre-editing some Japanese. What would normally happen next is that you either press "Space" to convert the phonetic text you've entered (a popup will appear at the cursor with some options), and/or "Return" to accept the text as it is currently. While in the pre-editing mode, the text at the cursor that the input method is handling is underlined, and in the case of LO also appears as selected text in the document

Reproducing the bug involves changing the font while the pre-editing mode is open within a comment, before pressing "Return" to confirm/exit.
Comment 5 retired 2014-08-11 06:48:37 UTC

-> NEW

Thanks Matthew for making this idiot proof description (Comment 4, and then back to initial Description).

I was able to reproduce the crash. Attaching a video (not too much too see - instead of mouse pointer, I was seeing the psycho pizza of death, after changing the font to "Bauhaus 93"). Interestingly the crash did not occur, when I changed the font to Times New Roman.

Crash log not attached, since we have that from Matthew already.
Comment 6 retired 2014-08-11 06:49:50 UTC
Created attachment 104410 [details]
Comment 7 Matthew Francis 2014-08-11 10:20:51 UTC
It looks like the originally attached backtrace actually related to the now fixed bug 82260 - the traces seem identical.

The issue that Foss successfully reproduced is however still present in git (which I have now built), and under a development build gives a rather different backtrace, which I will attach.
Comment 8 Matthew Francis 2014-08-11 10:21:54 UTC
Created attachment 104421 [details]
Updated backtrace
Comment 9 Matthew Francis 2015-01-19 05:30:55 UTC
Occurs all the way back to 3.3.0 (and still in

Setting Version to "Inherited from OOo"
Comment 10 QA Administrators 2016-02-21 08:36:37 UTC Comment hidden (obsolete)
Comment 11 Julien Nabet 2016-06-26 08:58:18 UTC
Any better with recent LO version? (last one is 5.1.4)
Comment 12 Julien Nabet 2016-06-26 09:21:03 UTC
With master sources updated yesterday, I could reproduce the hang.
Comment 13 Julien Nabet 2016-06-26 09:36:36 UTC
Created attachment 125911 [details]
bt with symbols
Comment 14 QA Administrators 2017-09-01 11:18:16 UTC Comment hidden (obsolete)
Comment 15 eisa01 2018-03-10 13:03:53 UTC
Had to try a couple times, but managed to reproduce this when changing the font to Bauhaus 93 as mentioned in comment #5

This is a niche data loss bug, so raising importance to critical
Comment 16 Julien Nabet 2019-05-29 13:59:04 UTC
I don't have a Mac anymore, could someone give it a try with last LO version 6.2.4 ?
Comment 17 eisa01 2019-06-08 10:58:14 UTC
Still occurs as of builds two months ago (no nightly builds available for download)

Build ID: ea9c13be02ba731074fa4207944ff7df40a0fb5c
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-04-10_20:43:17
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 18 Julien Nabet 2019-11-11 10:06:53 UTC
Matthew/eisa01: would you be interested in building LO code so we may:
- an up-to-date stacktrace
- add some patches to try to debug (I can submit patches to add some traces and you'd retrieve them so your build would show even more info)
Of course, it may help for other MacOs bugs.
If yes, you can take a look at https://wiki.documentfoundation.org/Development/BuildingOnMac
You must know that few LO devs use Macs and since it concerns CJK bugs, I think (I may be wrong) there's even less chance to have some update here.

Alex: do you still have some pb to build? If yes, perhaps we may ping Tor?
Comment 19 eisa01 2020-05-03 11:16:54 UTC
Still occuring

1. Create a new comment
2. Type aaa (in Hiragana)
3. Select the text aaa
4. Change font
5. Click after the aaa text
4. Press enter -> Crash

Build ID: 4db9852e73d9e9d662fc8a2783bace79addf1805
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 20 QA Administrators 2022-05-04 03:50:30 UTC
Dear Matthew Francis,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team