Crash in [@ JSString::isRope]
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox111 | --- | wontfix |
firefox112 | --- | affected |
firefox113 | --- | affected |
People
(Reporter: RyanVM, Unassigned, NeedInfo)
References
(Blocks 2 open bugs)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/cc156c8f-c8b7-4c0c-bcef-d0f870230405
Reason: SIGSEGV / SI_KERNEL
Top 10 frames of crashing thread:
0 libxul.so JSString::isRope const js/src/vm/StringType.h:474
0 libxul.so js::GCMarker::eagerlyMarkChildren< js/src/gc/TraceMethods-inl.h:105
0 libxul.so js::GCMarker::eagerlyMarkChildren< js/src/gc/TraceMethods-inl.h:82
0 libxul.so js::GCMarker::scanChildren< js/src/gc/Marking.cpp:1132
0 libxul.so js::GCMarker::traverse< js/src/gc/Marking.cpp:1093
0 libxul.so js::GCMarker::markAndTraverse< js/src/gc/Marking.cpp:1036
0 libxul.so js::GCMarker::markAndTraverseEdge< js/src/gc/Marking.cpp:1199
0 libxul.so js::GCMarker::processMarkStackTop< js/src/gc/Marking.cpp:1480
0 libxul.so js::GCMarker::markOneColor< js/src/gc/Marking.cpp:1337
1 libxul.so js::GCMarker::doMarking< js/src/gc/Marking.cpp:1279
Reporter | ||
Comment 1•2 years ago
|
||
Appears to have started a few months back with pretty consistent crash volume since.
Comment 2•2 years ago
|
||
The crash address in the linked report is 0x65672f3037303531
, which is not a valid pointer, but does spell out "eg/07051" in valid ASCII (or rather "15070/ge", because this is little-endian). So it appears that we try loading a pointer to the base string, and instead end up with a pointer to the contents of a string. Scanning through the list of reports, there are a few other crash addresses that look more like ASCII than pointers (0x65737361 = "asse", 0x5f726f7461657263 = "creator_", maybe 0x00293737 = "77)").
Not entirely sure what to make of that. If a cosmic ray flips a low bit in a pointer to an inline string, then the result might point to the character data instead. 4/74 crashes with ASCII is not that far off the percentage of potential bit flips that would lead to this result. On the other hand, if this assertion in base() is anything to go by, the base string shouldn't be an inline string to start with, so maybe that math doesn't hold up.
Comment 3•2 years ago
|
||
This is indeed strange to have so many string content, but this is likely to be due to the duality of our string implementation which has a union between pointers and in-place string content.
What seems a bit strange to me is the relatively high number of nightly/beta relative to the low number of release crashes for the same signature.
Comment 4•2 years ago
|
||
Steve, since you've been looking at string representation this seems potentially of interest to you.
Description
•