Closed Bug 1691627 Opened 4 years ago Closed 4 years ago

Firefox always crashes when I try to text with Chinese IME

Categories

(Core :: Layout: Text and Fonts, defect)

Firefox 85
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: t-x.h, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4400.0 Safari/537.36 Edg/90.0.782.0

Steps to reproduce:

This issue appears recently, so I guess it's caused by recent update to Firefox 85.0.1 (20210204182252)

  1. set Windows 10 (version 19042.746) locale to zh-CN
  2. open Firefox
  3. switch IME to Microsoft Pinyin
  4. Input anything in any textbox

It can be constantly reproduced.
Computer reboot can't solve it.

Actual results:

After the IME UI appears, the whole Firefox process crashes.

Expected results:

Text can be normally entered.

Safe mode or creating a new profile can't solve this problem, and Firefox will even crash when I'm texting with IME in non-webpage textbox.

I tried reproducing this issue on the latest versions of Firefox Nightly 87.0a1 (2021-02-15), beta 86.0b9 and release 85.0.2 but no crashes occurred for me.

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

Can you provide a crash report for this? See about:crashes in Firefox for links (if there are lots of reports listed, check the date/time to make sure you're choosing a report that corresponds to this problem).

Flags: needinfo?(t-x.h)

(In reply to Jonathan Kew (:jfkthame) from comment #4)

Can you provide a crash report for this? See about:crashes in Firefox for links (if there are lots of reports listed, check the date/time to make sure you're choosing a report that corresponds to this problem).

https://crash-stats.mozilla.org/report/index/801a05c5-17b3-4f1a-affc-2f8b20210209
https://crash-stats.mozilla.org/report/index/ec36ef39-e36b-415c-bb40-f5da50210209

Based on these reports, the crash seems caused by memory exhaustion.
My computer only has 8GB physical memory and it's often exhausted, but these reports shows there are still free memory at crash time.

Flags: needinfo?(t-x.h)

It looks like every one of the crash reports in nsTextFrame show the same thing:

Crash Reason EXCEPTION_PRIV_INSTRUCTION
Crash Address 0x7ffeab6a04b5

with addresses that vary somewhat, but always end with ...04b5. My reading of that is that it's always crashing on the same machine instruction, with the module being loaded at slightly different base addresses each time.

The report points to this being at https://hg.mozilla.org/releases/mozilla-release/file/30fa4718813e735a3b4a0a5135352bfe2a655a8b/layout/generic/nsTextFrame.cpp#l7417, which is pretty ordinary-looking code within nsTextFrame. I can't see any reason we'd suddenly be hitting a privileged instruction there in the midst of the code.

My current guess, then, is that there may have been a corrupted byte in the code there, so that something in the normal instruction stream was changed into a privileged instruction that isn't allowed in user code. How? I don't know; maybe a result of a bug elsewhere; or perhaps more likely, a disk read error resulting in the program code being misread.

It's interesting that it apparently happened a number of times (always affecting the exact same point in the code), but now it's stopped happening. Maybe there's a hardware component (memory chip? disk sector?) that's on the edge of failure, and isn't entirely reliable when read. Or maybe some other software component was causing the corruption, though it seems quite surprising that would so consistently hit the same spot in the loaded code, despite being loaded at different base addresses.

Just speculating here, really....

Jonathan's guess sounds really reasonable. I think it's my disk's fault. Thanks!

OK, let's close this for now. If the problem (or something like it) comes back, we can re-open for further investigation.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: