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

Kannan, nbp told me that this might be something for you. Could you take a look, thanks!

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.

guessing sec-high based on bugs with similar assertions, but just a guess at this point dupe/related to bug 1178767?

(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 ?

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.

(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

was able to get this into windbg on a win7 trunk build and the url from comment #0 - maybe this helps

Thanks for the repro info everyone. I'll take a look at this.

Kannan, did you have a chance to look at this?

No, it got waylaid between the flyweb stuff. I can work on it this week probably one or two days.

Hi Kannan, any time to look at this?

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.

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.

also not able to reproduce, maybe this was fixed by the other MIR Bugs ?