Closed Bug 1517317 Opened 6 years ago Closed 6 years ago

Crash in trunc

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox64 --- unaffected
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- fix-optional
firefox68 --- ?

People

(Reporter: marcia, Unassigned)

Details

(5 keywords)

Crash Data

This bug was filed from the Socorro interface and is report bp-eb023463-eb01-47d1-939a-3013e0181228. ============================================================= Seen while looking at 65 beta crash stats: https://bit.ly/2AnXInm. Crashes were present in nightly 65 before it moved to 66. No comments and the correlations don't seem to show much. Perhaps a signature change? Bug 1502542 was on file for Tbird but doesn't seem to be happening much in that product any more. Top 10 frames of crashing thread: 0 xul.dll trunc 1 xul.dll js::GCMarker::markUntilBudgetExhaused js/src/gc/Marking.cpp:1568 2 xul.dll js::gc::GCRuntime::incrementalSlice js/src/gc/GC.cpp:6985 3 xul.dll js::gc::GCRuntime::gcCycle js/src/gc/GC.cpp:7376 4 xul.dll js::gc::GCRuntime::collect js/src/gc/GC.cpp:7541 5 xul.dll JS::IncrementalGCSlice js/src/gc/GC.cpp:8454 6 xul.dll nsJSContext::GarbageCollectNow dom/base/nsJSEnvironment.cpp:1108 7 xul.dll static bool InterSliceGCRunnerFired dom/base/nsJSEnvironment.cpp:1729 8 xul.dll bool std::_Func_impl_no_alloc<`lambda at z:/build/build/src/dom/base/nsJSEnvironment.cpp:2231:13', bool, mozilla::TimeStamp>::_Do_call 9 xul.dll mozilla::IdleTaskRunner::Run xpcom/threads/IdleTaskRunner.cpp:58 =============================================================
We don't call trunc directly in the GC and there should be no floating point operations happening here.

Jon, can you think of anything that would be causing this signature to increase in occurrence (and to just have started in 65 beta)?

Nils, Marcia mentioned there were some YouTube URLs in the crash reports ... are they serving enough AV1 that we'd have hundreds of crashes? Yes, I'm taking a stab in the dark here :)

Flags: needinfo?(jcoppeard)
Flags: needinfo?(drno)

I think this is another random crash during GC and the stack is corrupt in some way that causes us to see this call to trunc. So I think it's just a different signature for one of the existing crashes.

Flags: needinfo?(jcoppeard)

As discussed during triage, I said I would look at crash-stats to see if there was anything useful in the way of comments or URLs.

Crash stats shows a fairly high correlation to a particular bios manufacturer: 62.34% in signature vs 38.72% overall) bios_manufacturer = American Megatrends Inc. [63.16% vs 15.21% if startup_crash = null]. At the moment there are no useful comments. youtube and GMail shows up pretty frequently in the URLs - but other than that I don't see a particular trend.

For Nightly crash reports, here are the correlations:

(29.17% in signature vs 03.21% overall) cpu_microcode_version = 0x25 [100.0% vs 20.55% if CPU Info = family 6 model 42 stepping 7]
(100.0% in signature vs 30.42% overall) abort_message = null
(66.67% in signature vs 06.02% overall) address = 0xffffffffffffffff
(33.33% in signature vs 02.06% overall) adapter_driver_version = 9.17.10.4229 [100.0% vs 61.03% if adapter_device_id = 0x0102]
(33.33% in signature vs 02.06% overall) adapter_driver_version_clean = 4229 [100.0% vs 61.03% if adapter_device_id = 0x0102]
(62.50% in signature vs 18.05% overall) Module "api-ms-win-core-timezone-l1-1-0.dll" = true
(62.50% in signature vs 18.05% overall) Module "api-ms-win-core-synch-l1-2-0.dll" = true
(62.50% in signature vs 18.05% overall) Module "api-ms-win-core-processthreads-l1-1-1.dll" = true
(62.50% in signature vs 18.07% overall) Module "lpk.dll" = true
(62.50% in signature vs 18.35% overall) Module "WSHTCPIP.DLL" = true
(29.17% in signature vs 02.48% overall) adapter_device_id = 0x0102 [58.33% vs 06.12% if adapter_vendor_id = 0x8086]
(58.33% in signature vs 99.95% overall) ipc_message_name = null
(50.00% in signature vs 09.80% overall) Module "atl.dll" = true
(62.50% in signature vs 18.07% overall) platform_pretty_version = Windows 7 [62.50% vs 23.59% if platform = Windows NT]
(45.83% in signature vs 07.25% overall) Module "msmpeg2adec.dll" = true
(33.33% in signature vs 03.89% overall) Module "igd10umd64.dll" = true [53.33% vs 12.96% if platform_pretty_version = Windows 7]
(29.17% in signature vs 01.48% overall) Addon "sovetnik-yandex@yandex.ru" = true
(29.17% in signature vs 01.50% overall) build_id = 20190101094742
(29.17% in signature vs 01.93% overall) Addon "SaveFrom.net helper all-in-1 / youtube downloader" = true
(29.17% in signature vs 02.02% overall) Addon "Визуальные закладки от Яндекс" = true
(58.33% in signature vs 12.17% overall) Module "cryptbase.dll" = true [92.86% vs 68.86% if platform_version = 6.1.7601 Service Pack 1]
(29.17% in signature vs 01.51% overall) adapter_subsys_id = 76801462 [38.46% vs 01.64% if startup_crash = null]
(29.17% in signature vs 02.52% overall) Addon "Dark Mode (WebExtension)" = true
(29.17% in signature vs 02.58% overall) Addon "Adguard AdBlocker" = true
(41.67% in signature vs 08.17% overall) Module "RpcRtRemote.dll" = true [66.67% vs 45.21% if platform_pretty_version = Windows 7]
(70.83% in signature vs 96.95% overall) Addon "webcompat-reporter@mozilla.org" = true
(45.83% in signature vs 10.55% overall) Module "slc.dll" = true [73.33% vs 49.37% if platform_pretty_version = Windows 7]
(50.00% in signature vs 10.45% overall) Module "ksuser.dll" = true [78.57% vs 53.99% if platform_version = 6.1.7601 Service Pack 1]

status-firefox67: --- → affected

trunc definitely needs to be added to the skip list; most of these are highly varying (though all looking real) stacks above trunc. Almost all of the crashes I see appear to be sec issues - many EXECs of wildptrs, for example, including in imgloader and jit (which are probably more worrying than GC crashes).

Group: core-security
Keywords: csectype-wildptr, sec-high

Adding Will for the skiplist part, see Comment 7.

Group: core-security → javascript-core-security

Regarding comment #8, Marcia created bug #1523968 and that was implemented and pushed out last week.

Would adding this to the skip list mean we shouldn't see these crashes listed under the trunc signature? Is there anything else that should be done in this bug or should we be filing new issues by digging through the underlying stacks?

Flags: needinfo?(rjesup)

Looks like the remaining ones have no named stackframes above trunc() :-(

Flags: needinfo?(rjesup)
Crash Signature: [@ trunc] → [@ trunc] [@ trunc | trunc | js::jit::MaybeEnterJit ]

Those may or may not be the same crash; clearly "trunc" is being mis-identified by the stack scan. In the original signature, it found nothing above it. In the one you added (which is only in 67), it finds MaybeJIT. No way to really know if they're the same. However the MaybeJIT crashes also appear to start in 65.0bN:

https://crash-stats.mozilla.com/signature/?hang_type=crash&product=Firefox&platform=Windows&process_type=browser&process_type=content&signature=trunc%20%7C%20trunc%20%7C%20js%3A%3Ajit%3A%3AMaybeEnterJit&date=%3E%3D2018-09-07T04%3A19%3A00.000Z&date=%3C2019-03-07T04%3A19%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

sdetar?

Flags: needinfo?(rjesup) → needinfo?(sdetar)

Jan, do you have any thoughts what to do with this? I know you might not be the right person, but might have some in-site. I am not sure what the next steps should be and looking for some help.

Flags: needinfo?(sdetar) → needinfo?(jdemooij)

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #10)

Would adding this to the skip list mean we shouldn't see these crashes listed under the trunc signature? Is there anything else that should be done in this bug or should we be filing new issues by digging through the underlying stacks?

Yes, please file new issues for different underlying stacks. Let's close this one.

Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jdemooij)
Flags: needinfo?(drno)
Resolution: --- → INVALID
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.