Closed
Bug 1178764
Opened 9 years ago
Closed 8 years ago
Assertion failure: MIR instruction returned object with unexpected type, at c:/mozilla/builds/nightly/mozilla/js/sr at js::Activation::asJit js::Activation::isProfiling js::Activation::registerProfiling js::jit::JitActivation::JitActivation EnterIon crash
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: cbook, Assigned: djvj)
References
()
Details
(Keywords: assertion, sec-high)
Attachments
(3 files)
spin off from bug 1175538 after talking to nbp on irc.
Bughunter found a crash on http://flight.qunar.com/site/interroundtrip_compare.htm?fromCity=%C3%83%C2%A5%C3%82%C2%BE%C3%82%C2%90%C3%83%C2%A5%C3%82%C2%B7%C3%82%C2%9E&toCity=%C3%83%C2%A5%C3%82%C2%8F%C3%82%C2%B0%C3%83%C2%A5%C3%82%C2%8C%C3%82%C2%97&fromDate=2015-06-25&toDate=2015-07-02&fromCode=XUZ&toCode=TPE&from=flight_int_search&ex_track=auto_50e69a47&lowestPrice=null&isInter=true&favorit
Assertion failure: MIR instruction returned object with unexpected type, at c:/mozilla/builds/nightly/mozilla/js/src/jit/MacroAssembler.cpp:1747
with the crash signature :
js::Activation::asJit js::Activation::isProfiling js::Activation::registerProfiling js::jit::JitActivation::JitActivation EnterIon crash
Reporter | ||
Comment 1•9 years ago
|
||
Kannan, nbp told me that this might be something for you. Could you take a look, thanks!
Flags: needinfo?(kvijayan)
Assignee | ||
Comment 2•9 years ago
|
||
This is an extremely weird assert to hit. The logic that is crashing effectively reduces to:
if (isJit()) {
asJit()...
}
reduces to:
if (isJit()) {
MOZ_ASSERT(isJit()); <-- crash happens here.
...
}
How reproducible is this? Having a debugger to step through this would be useful.
Flags: needinfo?(kvijayan)
Comment 3•9 years ago
|
||
guessing sec-high based on bugs with similar assertions, but just a guess at this point
dupe/related to bug 1178767?
Keywords: sec-high
Reporter | ||
Comment 4•9 years ago
|
||
(In reply to Kannan Vijayan [:djvj] from comment #2)
> This is an extremely weird assert to hit. The logic that is crashing
> effectively reduces to:
>
> if (isJit()) {
> asJit()...
> }
>
> reduces to:
>
> if (isJit()) {
> MOZ_ASSERT(isJit()); <-- crash happens here.
> ...
> }
>
> How reproducible is this? Having a debugger to step through this would be
> useful.
seems bughunter could reproduce, but for the debugger steps, good question. :bc do you know how we can help here ?
Flags: needinfo?(bob)
Comment 5•9 years ago
|
||
I can easily reproduce the message "Assertion failure: MIR instruction returned object with unexpected type" in a debug nightly build on linux x86_64 but this is not a true fatal assertion in that it doesn't cause a crash as far as I understand it. I do end up crashing the tab sometime after the assertion message appears however. I can't get a breakpoint set on js/src/jit/MacroAssembler.cpp:1746 nor get it in gdb.
For some readon My debug build doesn't fire the message
CHILDCHILDCHILDCHILD
debug me @ 99999
even with MOZ_DEBUG_CHILD_PROCESS=1 set.
I can reproduce the assertion and crash in non-e10s mode as well.
For one thing, the stack reported originally is only one of several that are appearing. It is unclear to me what is happening but I do see other stacks where the reason is an exception breakpoint but a register contains @xdeadbeef which I don't think we normally see as part of a MOZ_CRASH induced stack.
I have a feeling something bad is happening here, but I can't get it in a debugger. Sorry.
Flags: needinfo?(bob)
Reporter | ||
Comment 6•9 years ago
|
||
(In reply to Bob Clary [:bc:] from comment #5)
> Created attachment 8629684 [details]
> example linux x86_64 stack from bughunter
>
> I can easily reproduce the message "Assertion failure: MIR instruction
> returned object with unexpected type" in a debug nightly build on linux
> x86_64 but this is not a true fatal assertion in that it doesn't cause a
> crash as far as I understand it. I do end up crashing the tab sometime after
> the assertion message appears however. I can't get a breakpoint set on
> js/src/jit/MacroAssembler.cpp:1746 nor get it in gdb.
>
> For some readon My debug build doesn't fire the message
> CHILDCHILDCHILDCHILD
> debug me @ 99999
>
> even with MOZ_DEBUG_CHILD_PROCESS=1 set.
>
> I can reproduce the assertion and crash in non-e10s mode as well.
>
> For one thing, the stack reported originally is only one of several that are
> appearing. It is unclear to me what is happening but I do see other stacks
> where the reason is an exception breakpoint but a register contains
> @xdeadbeef which I don't think we normally see as part of a MOZ_CRASH
> induced stack.
eax=04363a28 ebx=002fcba8 ecx=0a3d56a0 edx=0ac3b36c esi=00000000 edi=0530822a
eip=00c417af esp=002fcbcc ebp=deadbeef iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
00c417af cc int 3
is what i get, also with the deadbeef - so far i was able to reproduce the problem from the url from comment #0
Reporter | ||
Comment 7•9 years ago
|
||
was able to get this into windbg on a win7 trunk build and the url from comment #0 - maybe this helps
Flags: needinfo?(kvijayan)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → kvijayan
Flags: needinfo?(kvijayan)
Assignee | ||
Comment 8•9 years ago
|
||
Thanks for the repro info everyone. I'll take a look at this.
Updated•9 years ago
|
Group: core-security → javascript-core-security
Assignee | ||
Comment 10•9 years ago
|
||
No, it got waylaid between the flyweb stuff. I can work on it this week probably one or two days.
Flags: needinfo?(kvijayan)
Assignee | ||
Comment 12•9 years ago
|
||
I'm sorry I have not had any time to dig into this. It's a pretty big context switch for me since it's been a while since I've done a spidermonkey build on windows and debugged it. I should have offloaded this earlier, but I didn't anticipate the timesink the flyweb work would be.
I have a bit of free time today, so I'll spend the rest of the day on it.
Flags: needinfo?(kvijayan)
Assignee | ||
Comment 13•9 years ago
|
||
Build on windows x64 (debug) off of trunk and was not able to repro this. Visited website plain and with profiling turned on during the visit. Trying to run it more times to see if I can repro.
Running currently on a win10 laptop.
Reporter | ||
Comment 14•9 years ago
|
||
also not able to reproduce, maybe this was fixed by the other MIR Bugs ?
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Updated•7 years ago
|
Group: javascript-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•