Open Bug 1826607 Opened 2 years ago Updated 2 years ago

Crash in [@ JSString::isRope]

Categories

(Core :: JavaScript Engine, defect, P3)

defect

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

Appears to have started a few months back with pretty consistent crash volume since.

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.

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.

Severity: -- → S4
Priority: -- → P3

Steve, since you've been looking at string representation this seems potentially of interest to you.

Flags: needinfo?(sfink)
You need to log in before you can comment on or make changes to this bug.