1390334 - Crash in js::jit::LIRGenerator::visitBlock

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[baffclan]

This bug was filed from the Socorro interface and is 
report bp-a2ca43e1-1037-43d5-a1e1-1cd5e0170814.
=============================================================

Crashing Thread (7)
Frame 	Module 	Signature 	Source
0 	xul.dll 	js::jit::LIRGenerator::visitBlock(js::jit::MBasicBlock*) 	js/src/jit/Lowering.cpp:5160
1 	xul.dll 	js::jit::LIRGenerator::generate() 	js/src/jit/Lowering.cpp:5228
2 	xul.dll 	js::jit::GenerateLIR(js::jit::MIRGenerator*) 	js/src/jit/Ion.cpp:1874
3 	xul.dll 	js::jit::CompileBackEnd(js::jit::MIRGenerator*) 	js/src/jit/Ion.cpp:1969
4 	xul.dll 	js::HelperThread::handleIonWorkload(js::AutoLockHelperThreadState&) 	js/src/vm/HelperThreads.cpp:1785
5 	xul.dll 	js::HelperThread::threadLoop() 	js/src/vm/HelperThreads.cpp:2174
6 	xul.dll 	js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) 	js/src/threading/Thread.h:227
7 	ucrtbase.dll 	o__strtoui64 	
8 	kernel32.dll 	BaseThreadInitThunk 	
9 	ntdll.dll 	RtlUserThreadStart 	



Application Basics: 
Name: Firefox
Version: 57.0a1
Build ID: 20170814100258
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
OS: Windows_NT 10.0

Comment 1

[Naveed Ihsanullah [:naveed]]

Nicolas please evaluate if this is actionable for FF57.

Comment 2

[Nicolas B. Pierron [:nbp]]

I look deeply in the code and crash addresses of these crashes, and once more I have to say that these do no make sense.

One of the most frequent offset-from likely aligned pointers is 0x38 offset [1]. For an instruction field, this would correspond to the resumePoint_ field of the MInstruction.  For a vtable pointer, this would be the possiblyCall function.

The possiblyCall function would match the call made here http://searchfox.org/mozilla-central/rev/1c13d5cf85f904afb8976c02a80daa252b893fca/js/src/jit/Lowering.cpp#5085

Still, this does not sounds logical, because our LIR should never free any MIR, and thus should not change any vtable pointer.  Thus the vtable for the accept function should be the same vtable as the one used by the accept function.

Checking the aggregation of reasons [1], highlight that these are most likely a READ crash.  Thus more likely reas to the resumePoint_ field, with a buggy MInstruction pointer.  This buggy MInstruction pointer does not makes sense either, because we are iterating over the graph many-many times before reaching the LIRGenerator.

The up-time of these crashes seems to indicate start-up crashes, but no URL seems to be valid (really about:blank ?)

A few crashes have a moz-crash reason:
 · MOZ_RELEASE_ASSERT(is<T>())   (http://searchfox.org/mozilla-central/search?q=MOZ_RELEASE_ASSERT(is%3CT%3E())&case=false&regexp=false&path=)
 · MOZ_RELEASE_ASSERT(success)   (http://searchfox.org/mozilla-central/search?q=MOZ_RELEASE_ASSERT%28success%29&path=)

In both cases, these assertions are reporting the same stack, but we are not using either Variant nor Threads in the LIRGenerator.

I do not think this bug is actionable in its current state.


[1] https://crash-stats.mozilla.com/signature/?product=Firefox&address=%2438&signature=js%3A%3Ajit%3A%3ALIRGenerator%3A%3AvisitBlock&date=%3E%3D2017-03-19T12%3A52%3A36.000Z&date=%3C2017-09-19T12%3A52%3A36.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-version&_sort=-date&page=1