Firefox always crashes when I try to text with Chinese IME
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: t-x.h, Unassigned)
Details
Attachments
(1 file)
16.13 KB,
text/plain
|
Details |
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)
- set Windows 10 (version 19042.746) locale to zh-CN
- open Firefox
- switch IME to Microsoft Pinyin
- 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.
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
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).
(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.
https://crash-stats.mozilla.org/report/index/801a05c5-17b3-4f1a-affc-2f8b20210209
This one seems from other crash scenario.
https://crash-stats.mozilla.org/report/index/ec36ef39-e36b-415c-bb40-f5da50210209
This one is from nsTextFrame which should be related to IME.
Other crash reports from nsTextFrame:
https://crash-stats.mozilla.org/report/index/acc74ff4-1ff5-4ffa-a069-b27260210216
https://crash-stats.mozilla.org/report/index/d6c0e594-e1e0-4172-a88d-7c8200210216
https://crash-stats.mozilla.org/report/index/34710c61-9946-48ba-95fb-5d4670210216
https://crash-stats.mozilla.org/report/index/ad12cb4e-8841-4aac-89ca-4cbb20210216
https://crash-stats.mozilla.org/report/index/bb97e5dd-4900-400f-83b5-03a000210216
https://crash-stats.mozilla.org/report/index/7f3dd604-050b-4fab-919f-aeb780210216
https://crash-stats.mozilla.org/report/index/31bb5646-4c69-4dab-9706-cc9550210216
In addition, after several reboots, this problem doesn't occur now.
Comment 7•4 years ago
|
||
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!
Comment 9•4 years ago
|
||
OK, let's close this for now. If the problem (or something like it) comes back, we can re-open for further investigation.
Description
•