Closed Bug 492028 Opened 11 years ago Closed 11 years ago

TM: Crash [@ nsEventReceiverSH::AddEventListenerHelper]


(Core :: JavaScript Engine, defect, P1)






(Reporter: bc, Assigned: gal)



(Keywords: crash, regression, verified1.9.1, Whiteboard: fixed-in-tracemonkey)

Crash Data


(1 file, 2 obsolete files)

Beginning with today's build (20090508) on linux, Minefield crashes on startup. It may be related to my add-ons and/or profile. It appears related to JIT however.


top o' stack:

0  	nsEventReceiverSH::AddEventListenerHelper  	jsobj.h:254
1 		@0x673af37 	
2 		@0xbfb40787 	
3 	js_MonitorLoopEdge 	js/src/jstracer.cpp:4667
4 	js_Interpret 	js/src/jsinterp.cpp:3279
5 	js_Invoke 	js/src/jsinterp.cpp:1375
6 	js_InternalInvoke 	js/src/jsinterp.cpp:1428
7 	JS_CallFunctionValue 	js/src/jsapi.cpp:5191

I'll try to narrow down the variables.
Flags: blocking1.9.1?
Priority: -- → P1
Summary: Crash [@ nsEventReceiverSH::AddEventListenerHelper] → TM: Crash [@ nsEventReceiverSH::AddEventListenerHelper]
Priority: P1 → --
Bob, can you identify the guilty patch? I assume its this one:

But confirmation would be good.
Priority: -- → P1
can this be duped to Bug 492029 or vv ?
The crash only occurs with chrome jit. I'll try before and after the patch, but this is a relatively slow T42 and it'll take a little while.

You make the call, but I beat him by seconds! ;-)
Looks like we are passing the wrong object here?
Duplicate of this bug: 492029
This also happens on Vista HP SP1, Platform = All ?
OS: Linux → All
(In reply to comment #1)
> Bob, can you identify the guilty patch? I assume its this one:
> But confirmation would be good.

yes, bug 487134 confirmed to be the regressor.
Blocks: 487134
I hit this multiple times doing a trunk nightly update to Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090508 Minefield/3.6a1pre today.  It must be something with my profile though.

After doing the software update, restarting minefield will immediately crash and pop open the crash reporter.  This is on OSX.
if needed, i have a profile that reproductively causes the crash.  let me know if its needed for further investigation.
Duplicate of this bug: 492057
nightly update 20090509 continues to cause a crash after install of the update, same as yesterday's This crash is unrecoverable.  Firefox/Minefield crashes upon starting also after installation of the full download
Flags: blocking1.9.1? → blocking1.9.1+
Same for update 20090511
(In reply to comment #12)
> Same for update 20090511

Thanks but daily reports of 'still not working' is not needed.  Please follow along with the bug, its not even assigned to anyone yet, when it is, they will write a patch, ask for review and then it will be checked into M-C, until then.. there is no need for repeated postings of still having a problem.  

Who owns this?
Bisect help?

see comment 7 for the results of bisection already done.
By the look of it, this is now #1 topcrash on trunk. Crashes start 20090508. Clear spike from 0 to several thousand occurrences.
Whoops, already bisected :) urr.
Duh, sorry -- Andreas, you want to take this one?

Jorendorff is the better match for this. Or we just back out the offending patch. Its not a 3.5 blocker.
We have a fuzzer bug open for the same bug. If sayrer feels we have the time to go after that right now, I will try to fix that and then we can see if this goes away.
Per Comment 20, if the offending bug is not a blocker, is there a reason why this is a blocker?  

Andreas, what's the bug you are referring to in Comment 21?

I don't have to say that any pruning of blockers we can do now...
The story is a bit complicated.

This is the offending patch is bug 487134.

It allows us to trace constructors, which fixes a few performance issues (i.e. creating a lot of Date object on trace). This is NOT a blocker, but "wanted?" by brendan.

While 487134 is not a blocker, it fixes bug 487240, which IS a blocker. We have no separate patch for 487134, but it can be done without too much effort. Backing out 487134 will be some mild pain though.

I am looking into bug 491989, which is also a regression from bug 487134 and I can probably fix it quickly. I don't think its the same issue though.

I can't reach jorendorff. If he is still on vacation today, I don't think we have time for bug 487134 (even though its very wanted), and we should back out.

Any other opinions? Brendan?
I just landed 2 patches for 487134. Might be worth retesting with TM tip.
Diagnosed (we think). Working on a patch.
Assignee: general → gal
Marginal improvement on SS, but measurable speedup on v8 benchmarks (which are very OO-ish).
Attachment #377031 - Attachment is obsolete: true
My try server run was hit by the maintenance window, but it seems I cycled all the columns that didn't get killed. I can't land my patch without Blake's part of this since we are not wrapping 'this' any more which is blatantly unsafe. We are hoping that we can get the security changes done tonight and then land it tonight. trunk users are really hurting ...
Attached patch v2Splinter Review
Attachment #377032 - Attachment is obsolete: true
Attachment #377289 - Flags: review?(mrbkap)
Comment on attachment 377289 [details] [diff] [review]

Holding my breath... It would be amazing if we could actually systematically verify the assumptions this patch is based on. :-/
Attachment #377289 - Flags: review?(mrbkap) → review+
I appologize for taking so long to fix this. It took us a while go figure out the right approach.
Whiteboard: fixed-in-tracemonkey
Closed: 11 years ago
Resolution: --- → FIXED
v 1.9.2 mac/linux. thanksomucho!
No more crashes listed for nsEventReceiverSH::AddEventListenerHelper in the last days since those fixes were checked in. Marking as verified.
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Crash Signature: [@ nsEventReceiverSH::AddEventListenerHelper]
You need to log in before you can comment on or make changes to this bug.