1322655 - Firefox 50.0.2 crashes when a webform hold exactly 102 capital "X"

Status: RESOLVED FIXED

(Core :: Spelling checker, defect)

Description

[Pontus]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Steps to reproduce:

In Firefox 50.0.2 - Open any writable text field in a webpage. (This text field I'm writing in is included).
Type in Exactly 102 capital "X" characters.

Writing more than 102 capital "X" in one row does not cause the crash.
Writing less than 102, cause no crash.

So all "X"'s are in a row, like the one I've provided bellow (This issue was reported from Google Chrome as Firefox crashes when this is pasted):
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



Actual results:

Firefox crashes.


Expected results:

It should show the 102 capital "X" characters.
Like this(Reported from Google Chrome browser):
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Firefox should not have crashed.

Comment 1

[Wayne Mery (:wsmwk)]

Is this a for real report?  (Sorry, doesn't sound like it)
Does it happen in safe mode?
 https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode?redirectlocale=en-US&redirectslug=Safe+Mode

Comment 2

[Pontus]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1)
> Is this a for real report?  (Sorry, doesn't sound like it)
> Does it happen in safe mode?
>  https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode?redirectlocale=en-US&redirectslug=Safe+Mode

Hi Wayne Mery.
Yes, this is infact a real report.
Strange as it sounds, I can replicate this exact issue running Firefox in safemode as well.

All that I need to do is to copy the 102 "X" characters I've provided in the above report, and paste it in this comment field. And Firefox, Eventho it's running in safemode crashes.

I've also confirmed the same issue occuring on several nodes.

Please try it yourself.

br 
Pontus

Comment 3

[Pontus]

I've been able to reproduce this in Windows 7 & Windows 10 
On Firefox v49.x.x & v50.0.2

Comment 4

[Wayne Mery (:wsmwk)]

Nope, no crash here - upper and lower case.

Please post your crash ID (as text string) from help | troubleshooting or about:crashes

Comment 5

[YF (Yang)]

WFM in Fx50.0.2 on Win10. Crash ID is needed.

Comment 6

[Pontus]

Hi Wayne Mery, and YF.

bp-d3877e6d-590e-427f-ae69-0f54b2161209

After re-installation of Firefox on a node where this issue could not be seen, I managed to narrow down to this being an issue with the (x86 sv-SE) version of Firefox.
I cannot replicate the issue in Firefox (x86 en-GB).


The error given in Visual Studio's Debugger is the following:

Unhandled exception at 0x5C74A9E0 (xul.dll) in firefox.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.

Bellow you will find the text from troubleshooting page (this provided in Swedish as this is the installation language):

Programfakta
------------

Namn: Firefox
Version: 50.0.2
Versions-ID: 20161129173726
Uppdateringskanal: release
Användaragent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
OS: Windows_NT 10.0
Multiprocess fönster: 1/1 (Aktiverad som standard)
Felsäkert läge: false

Kraschrapporter för de senaste 3 dagarna
----------------------------------------

Alla kraschrapporter

Tillägg
-------

Namn: Application Update Service Helper
Version: 1.0
Aktiverad: true
ID: [e-mail]

Namn: Multi-process staged rollout
Version: 1.5
Aktiverad: true
ID: [e-mail]

Namn: Pocket
Version: 1.0.5
Aktiverad: true
ID: [e-mail]

Namn: Web Compat
Version: 1.0
Aktiverad: true
ID: [e-mail]

Grafik
------

Funktioner
Komposition: Direct3D 11
Asynkron panorera/zoom: hjulinmatning aktiverad
WebGL-renderare: Google Inc. -- ANGLE (Intel(R) HD Graphics 5500 Direct3D11 vs_5_0 ps_5_0)
WebGL2-renderare: (no info)
H264 hårdvaruavkodning: Yes; Using D3D11 API
Ljudgränssnitt: wasapi
Direct2D: true
DirectWrite: true (10.0.10586.633)
GPU #1
Aktiv: Ja
Beskrivning: Intel(R) HD Graphics 5500
Leverantörs-ID: 0x8086
Enhets-ID: 0x1616
Drivrutinsversion: 20.19.15.4483
Drivrutinsdatum: 7-1-2016
Drivrutiner: igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
Kortleverantörs-ID: 503617aa
RAM: Unknown

Diagnostik
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
Beslutslogg
D3D9_COMPOSITING:
disabled by default: Disabled by default




Viktiga ändrade inställningar
-----------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 1
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 8
browser.sessionstore.upgradeBackup.latestBuildID: 20161129173726
browser.startup.homepage_override.buildID: 20161129173726
browser.startup.homepage_override.mstone: 50.0.2
browser.tabs.remote.autostart.2: true
browser.urlbar.daysBeforeHidingSuggestionsPrompt: 3
browser.urlbar.lastSuggestionsPromptDate: 20161209
extensions.lastAppVersion: 50.0.2
gfx.crash-guard.d3d11layers.appVersion: 50.0.2
gfx.crash-guard.d3d11layers.deviceID: 0x1616
gfx.crash-guard.d3d11layers.driverVersion: 20.19.15.4483
gfx.crash-guard.d3d11layers.feature-d2d: true
gfx.crash-guard.d3d11layers.feature-d3d11: true
gfx.crash-guard.status.d3d11layers: 2
gfx.crash-guard.status.d3d11video: 2
media.gmp-eme-adobe.abi: x86-msvc-x64
media.gmp-eme-adobe.lastUpdate: 1481316200
media.gmp-eme-adobe.version: 17
media.gmp-gmpopenh264.abi: x86-msvc-x64
media.gmp-gmpopenh264.lastUpdate: 1481316201
media.gmp-gmpopenh264.version: 1.6
media.gmp-manager.buildID: 20161129173726
media.gmp-manager.lastCheck: 1481316199
media.gmp-widevinecdm.abi: x86-msvc-x64
media.gmp-widevinecdm.lastUpdate: 1481316202
media.gmp-widevinecdm.version: 1.4.8.903
media.gmp.storage.version.observed: 1
media.hardware-video-decoding.failed: false
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
security.sandbox.content.tempDirSuffix: {ee61e0ce-8e19-4c16-899f-b30a4875f476}
ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found.

Viktiga låsta inställningar
---------------------------

Platser databas
---------------

JavaScript
----------

Incremental GC: true

Tillgänglighet
--------------

Aktiverad: false
Förhindra tillgänglighet: 0

Biblioteksversioner
-------------------

NSPR
Förväntad minimiversion: 4.12
Version som används: 4.12

NSS
Förväntad minimiversion: 3.26.2
Version som används: 3.26.2

NSSSMIME
Förväntad minimiversion: 3.26.2
Version som används: 3.26.2

NSSSSL
Förväntad minimiversion: 3.26.2
Version som används: 3.26.2

NSSUTIL
Förväntad minimiversion: 3.26.2
Version som används: 3.26.2

Experimentella funktioner
-------------------------

Sandbox
-------

Content Process Sandbox Level: 1


These two bellow provided error reports have been taken from the Windows Event Viewer

Faulting application name: firefox.exe, version: 50.0.2.6177, time stamp: 0x583e4bb4
Faulting module name: xul.dll, version: 50.0.2.6177, time stamp: 0x583e5163
Exception code: 0xc0000409
Fault offset: 0x006ba9e0
Faulting process id: 0x1ba0
Faulting application start time: 0x01d2525c803d7dea
Faulting application path: C:\Program Files (x86)\Mozilla Firefox\firefox.exe
Faulting module path: C:\Program Files (x86)\Mozilla Firefox\xul.dll
Report Id: 2f15b8ee-63da-4623-ab60-afe2fbbff0ee
Faulting package full name: 
Faulting package-relative application ID: 

Faulting application name: firefox.exe, version: 50.0.2.6177, time stamp: 0x583e4bb4
Faulting module name: mozglue.dll, version: 50.0.2.6177, time stamp: 0x583e4b91
Exception code: 0x80000003
Fault offset: 0x0000ed43
Faulting process id: 0x1cac
Faulting application start time: 0x01d2525c81af0629
Faulting application path: C:\Program Files (x86)\Mozilla Firefox\firefox.exe
Faulting module path: C:\Program Files (x86)\Mozilla Firefox\mozglue.dll
Report Id: de6c5eec-5f8f-4881-bdeb-d19cda88a806
Faulting package full name: 
Faulting package-relative application ID:

Comment 7

[YF (Yang)]

WFM in https://ftp.mozilla.org/pub/firefox/releases/50.0.2/win32/sv-SE/Firefox%20Setup%2050.0.2.exe with paste "X"x101 and TYPE the "X" on this bug's search box, on Win10 (zh-CN).


(In reply to Pontus from comment #0)
> Type in Exactly 102 capital "X" characters.

How do you do it? Enter these characters one by one with keyboard? Or paste can also be reproduced?

> Writing more than 102 capital "X" in one row does not cause the crash.

It does not crash right away? If it crashes immediately, how do you enter more characters?

> Writing less than 102, cause no crash.

See above.

Comment 8

[Pontus]

(In reply to YF (Yang) from comment #7)
> How do you do it? Enter these characters one by one with keyboard? Or paste
> can also be reproduced?

Both options seem to cause the crash.
I mainly paste from clipboard to replicate this issue as this directly cause the crash.

The time it takes for Firefox to crash is between a instant and a few milliseconds.
For some pages tested, I need to leave the text field.
This is the case here on this page, in the comment field.

> > Writing more than 102 capital "X" in one row does not cause the crash.
> 
> It does not crash right away? If it crashes immediately, how do you enter
> more characters?

The time it takes for Firefox to crash seem to between a instant and a few milliseconds.
the time varies everytime I've tried to replicated the issue.
Sometimes there is enough time to add letter or more, tho pasting 102 "X" usually crashes the browser instantly.
Therefor holding down "X" untill it's 102 or more usually does not render a crash.


Thank you for taking time investigating this.

br
Pontus

Comment 9

[YF (Yang)]

I have reproduced it with comment 7 configuration, except that these characters are pasted into comment field (appears after login). It crashes silently for many times, but there are no crash reports and crash reporter appears.

When the session resumed after crashes, I clicked the comment field to focus, the browser hang and silently shutdown after a few seconds.

Comment 10

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Oh, so I think this is actually trivial to fix. I suspect I can just change 176 back to 100 in https://github.com/hunspell/hunspell/commit/5de5239f2beac8d22b692dc9db57c821ba321116 and be done with it.

And file an upstream issue about guarding that with an #ifndef so it can be set at build time without requiring hacking the upstream source ;)

Comment 11

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Sorry, that was intended for bug 1322666, but it'll probably fix this bug too!

Comment 12

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Dimitrij, you should probably be aware of this bug for Hunspell2 testing. I'm going to tentatively assume that bug 1322666 will work around it on our end for now.

Comment 13

[Dimitrij Mijoski]

This bug can be reproduced in Firefox versions that use Hunspell 1.4.1, but only when certain dictionaries are selected. I was not able to reproduce using en_US or Hungarian, but I was able to reproduce it using the Korean dictionary installed via the package manager of Ubuntu 16.04 (and probably the same Korean dictionary is used in the Firefox addon).

It is possible that this bug is already fixed in Hunspell 1.5.x which already landed in Firefox tree and is planned for Firefox 53 AFAIK. I will try to reproduce the bug outside Firefox, directly with the Hunspell command line binary.

Comment 14

[Dimitrij Mijoski]

I was able to reproduce this bug with both 1.4.1 and the latest 1.5.4. Therefore I will file an issue in the Hunspell bugtracker, once fixed, 1.5.5 will be released.

Probably this bug existed since ages, but the MAXWORDLEN limit was 100 and was not allowing the bug to be triggered. Once the limit was raised to 176 in 1.4, the bug can be triggered. And yesterday, that limit was reverted to 100 only in the Mozilla source tree, so this bug will be hidden again. On the Mozilla side we are kinda safe.

Until i fix it for real in upstream and not just hiding it with MAXWORDLEN, it would help to tell me with which dictionaries this bug can be reproduced. So far I can do it only with Korean.

Comment 15

[Dimitrij Mijoski]

https://github.com/hunspell/hunspell/issues/446

Comment 16

[Dimitrij Mijoski]

I fixed this this in the upstream Hunspell, see the link to the issue above.

Comment 17

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Thanks, Dimitrij!

Comment 18

[Dimitrij Mijoski]

I published Hunspell v1.6.0 where this is fixed. It's up to Ryan to merge it in the source tree.

Comment 19

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Yeah, I intend to close it out once this bug lands.

Comment 20

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

This was fixed on Nightly by the Hunspell update in bug 1326277 and worked around for Firefox 51/52 by bug 1322666.