Crash in icu_62::DecimalFormat::setGroupingUsed
Categories
(Core :: JavaScript: Internationalization API, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox62 | --- | unaffected |
| firefox63 | --- | wontfix |
| firefox64 | --- | wontfix |
| firefox65 | --- | wontfix |
| firefox66 | --- | fix-optional |
People
(Reporter: philipp, Unassigned)
References
Details
(Keywords: crash, csectype-nullptr, regression)
Crash Data
Updated•7 years ago
|
Updated•7 years ago
|
Comment 2•7 years ago
|
||
Comment 3•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 4•7 years ago
|
||
The upstream ticket doesn't seem to be going anywhere. Is there any chance we could hack around this on our end for now?
Comment 5•7 years ago
|
||
To make this reproducible for me, I've built a shell with JS_SetICUMemoryFunctions setting ICU's allocation functions to use js_malloc and friends, which allows to create an oomTest function test case:
oomTest(function() {
for (var i = 0; i < 10; ++i) {
new Intl.DateTimeFormat("de").format(0)
}
})
And I got the crash from comment #0 right away. \o/
Added some fixes to catch the case when fields is nullptr when created from here and that should be it, right? Rebuild ICU and reran the oomTest test to ensure the newly added workarounds did indeed fix this crash. Nope, next crash happened, now fields->formatter created here is nullptr. Added more workarounds, which, by the way, involved making the DecimalFormat class non-functional, because not all users of fields->formatter have a way to report an error. And again, rebuild ICU and reran the oomTest. Next crash because Calendar::fZone created here is nullptr, but all Calendar users expect this field is never null.
After that crash I stopped playing whack-a-mole with ICU. /o\
So I don't think we can (successfully) hack around this without changing dozens of places in ICU. :-/
Comment 6•7 years ago
|
||
OK, thanks for trying :(. Doesn't sound like this bug is actionable until upstream gets around to fixing it.
Comment 7•7 years ago
|
||
I've looked into this sort of problem before -- André could fill people in on the details if it mattered -- and reached the same conclusion about lots of places in ICU requiring a fix, and that fix being too complicated to take anywhere but upstream first.
I don't think this is so critical as to prioritize over other work, but we always could if OOM issues that will mostly manifest on 32-bit are worth caring about super-strongly. It's hard for me to see why we would think that.
Updated•7 years ago
|
Comment 8•7 years ago
|
||
Comment 9•5 years ago
|
||
There was a very low volume of crashes in the last 6 months and all of them happened on ~FX67, not the latest Firefox versions.
Closing this as resolved:worksforme, please do re-open it if this crash will appear on the latest version of Firefox.
Description
•