519363 - topcrash [@js_Interpret] in "do_getprop_with_obj:" section with null dslots

Status: RESOLVED DUPLICATE of bug 524743

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

This is meant to be the "real" bug for this current topcrash. See http://tinyurl.com/y9xpqcn for the list. So far, not much info.

Comment 1

[David Mandelin [:dmandelin]]

js_Interpret is a huge function that contains a case for each JS bytecode. I grouped the crashes by source line in js_Interpret. Here are the top 5:

 214 4436 http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/0da982f65d37/js/src/jsinterp.cpp#l4436
  71 3887 http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/0da982f65d37/js/src/jsinterp.cpp#l3887
  40 4432 http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/0da982f65d37/js/src/jsinterp.cpp#l4432
  13 3883 http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/0da982f65d37/js/src/jsinterp.cpp#l3883
  11 5120 http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/0da982f65d37/js/src/jsinterp.cpp#l5120

Comment 2

[David Mandelin [:dmandelin]]

Here is a histogram of the crash addresses for the line 4436 crashes. Most of them are in the range 0-24, mostly at 0 or 4.

 117 0x0
  38 0x4
  15 0xc
  13 0x8
   5 0x14
   4 0x10
   3 0x1bc
   2 0xec7c0
   2 0x23e7c0
   1 0xffffffffffffffff
   1 0xffffffffffffffa8
   1 0xffffffffffefffe8
   1 0xffffffffc057fd2c
   1 0xffffffffae5e47ec
   1 0x96d014
   1 0x64
   1 0x48
   1 0x259fa94
   1 0x1c
   1 0x1a
   1 0x18
   1 0x1423cc04
   1 0x13b62c30
   1 0x118461

Comment 3

[David Mandelin [:dmandelin]]

The crash seems to have started occurring with the 3.5b99 release. 3.5b4 was the last release without it. The revs are:

author	ffxbld
	Thu Apr 23 18:44:00 2009 -0700 (at Thu Apr 23 18:44:00 2009 -0700)
branch	GECKO191b4_20090423_RELBRANCH
changeset 25057	a476cb442514
parent 25056	8b7f53e910d6
pushlog:	a476cb442514


author	ffxbld
	Fri Jun 05 14:41:34 2009 -0700 (at Fri Jun 05 14:41:34 2009 -0700)
branch	GECKO191b99_20090604_RELBRANCH
changeset 25902	fcfaa3a2dea8
parent 25901	35432788a56e
pushlog:	fcfaa3a2dea8

Comment 4

[David Mandelin [:dmandelin]]

Our current hypothesis is that at the point of the crash, |obj2->dslots| is NULL. The reason we think this is that of all the x86 instructions that implement line 4436, only one has the ability to load from addresses 0x0, 4, 8, and c (given that a register is 0, i.e., assuming a null pointer is at the root of this), namely:

  mov eax, DWORD PTR [edx + eax*4 - 20]

This implements LOCKED_OBJ_GET_SLOT. edx is |obj2->dslots|. This line is reached only if (eax >= 5).

What things can cause |dslots| to be null?

- Newly allocated objects have |dslots| == 0. Of course, such an object should never try to get anything from slot 5 or greater. This bug is in a code path for a property cache hit, so this could happen if the property cache contains a bad entry that causes us to try to read from slot 5 for an object with no properties.

- When objects are freed, |dslots| is set to 0. Thus, if there is a GC bug and reachable objects are freed, they could get |dslots| 0 and this crash.

- When a slot is deleted, |dslots| can be set to 0. Again, such an object should not try to get anything from slot 5, so this would seem to require property cache corruption again.

- General memory corruption. But this seems an unlikely cause of a crash that is common at a certain point.

Comment 5

[David Mandelin [:dmandelin]]

Here is a trie view (like trace-malloc) of 200 or so call stacks of crashes. Most of the crashes are from direct invocations of methods through nsXPCWrappedJSClass::CallMethod or JS_CallFunctionValue. This gives me a slight suspicion that this crash is related to calling methods on native objects and property cache invariant breakage.

208 js_Interpret js/src/jsinterp.cpp:4436
  203 js_Invoke js/src/jsinterp.cpp:1394
    168 nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1697
      168 nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:569
        168 PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
          168 SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
            164 nsEventListenerManager::HandleEventSubType content/events/src/nsEventLi
stenerManager.cpp:1098
              1 nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:428
                1 xul.dll@0x8a568b 
              1 nsAutoCompleteController::ProcessResult toolkit/components/autocomplete
/src/nsAutoCompleteController.cpp:1284
                1 free obj-firefox/memory/jemalloc/src/jemalloc.c:6404
                  1 nsNavHistory::PerformAutoComplete toolkit/components/places/src/nsN
avHistoryAutoComplete.cpp:626
              1 nsDOMEventListenerWrapper::HandleEvent content/base/src/nsXMLHttpReques
t.cpp:183
                1 nsEventListenerManager::HandleEventSubType content/events/src/nsEvent
ListenerManager.cpp:1098
              1 nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:465
                1 nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:512
     30 js_InternalInvoke js/src/jsinterp.cpp:1447
       29 JS_CallFunctionValue js/src/jsapi.cpp:5187
         22 nsXBLProtoImplAnonymousMethod::Execute content/xbl/src/nsXBLProtoImplMethod
.cpp:332
           22 nsBindingManager::ExecuteDetachedHandlers content/xbl/src/nsBindingManage
r.cpp:1041
             22 nsGlobalWindow::PostHandleEvent dom/src/base/nsGlobalWindow.cpp:2353
               22 nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsE
ventDispatcher.cpp:303
                 22 nsEventTargetChainItem::HandleEventTargetChain content/events/src/n
sEventDispatcher.cpp:354
                   22 nsCOMPtr_base::assign_from_qi obj-firefox/xpcom/build/nsCOMPtr.cp
p:96
                     22 @0x5 
          7 nsJSContext::CallEventHandler dom/src/base/nsJSEnvironment.cpp:2035
            4 nsJSEventListener::HandleEvent dom/src/events/nsJSEventListener.cpp:247
              4 nsEventListenerManager::HandleEventSubType content/events/src/nsEventLi
stenerManager.cpp:1098
                4 nsEventListenerManager::HandleEvent content/events/src/nsEventListene
rManager.cpp:1206
                  4 nsEventTargetChainItem::HandleEvent content/events/src/nsEventDispa
tcher.cpp:236
                    3 nsEventTargetChainItem::HandleEventTargetChain content/events/src
/nsEventDispatcher.cpp:324
                      3 nsEventDispatcher::Dispatch content/events/src/nsEventDispatche
r.cpp:514
                        3 PresShell::FireResizeEvent layout/base/nsPresShell.cpp:2896
                          3 PresShell::sResizeEventCallback layout/base/nsPresShell.cpp
:2877
                            3 nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:420
                              3 nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:512
                                3 nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp

Comment 6

[David Mandelin [:dmandelin]]

jorendorff, my current hypothesis is that this has to do with the property cache, so I'm asking for some help. I'm specifically looking at the crashes on line 4436. Based on that location, I know that:

  - The current opcode is GETPROP or a relative
  - We got a property cache hit
  - obj->map->ops->getProperty == js_GetProperty
  - sprop->getter != 0 OR sprop->slot >= scope->freeslot

Based on the crash addresses, it looks like |pobj->dslots| is 0 (pobj in NATIVE_GET; this is the same as obj2 in the interp case). If this is true, then we are getting a cache hit telling us to use a slot >= 2 on an object that has <= 2 slots. Note that if I am right about dslots being 0, then we are in the  (SPROP_HAS_STUB_GETTER(sprop)) case of NATIVE_GET. (This is a little troubling, because there is some suspicion this might be related to special getters doing funky things, but maybe getters acting up is unlikely anyway.)

Based on the revision ranges above, there is reason to believe that the bug might have been introduced by http://hg.mozilla.org/releases/mozilla-1.9.1/rev/872f676e5d1a. This is one of 4 patches in the regression range that touches js_FillPropertyCache, and in particular it changes the case where an sprop is the cached value (the same case we are crashing on).

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/aa549e1ca3fb is another change that plausibly could have introduced this.

Right now I'm hoping to come up with a test case that returns the wrong object from the property cache, and then crashes trying to read the slot.

Comment 7

[David Mandelin [:dmandelin]]

Currently analyzing the minidump for 1eced902-7acc-4701-adcb-570882090928.

Comment 8

[David Mandelin [:dmandelin]]

We found some additional info in the minidump, and some corrections to what went above. The control flow is now believed to be this:

  - inside getprop, we get a prop cache hit
  - the hit is of an SPROP entry, so we go that way in the if-else series
  - the property getter is *non-stub* (corrected from above)
  - we now inline into js_NativeGet
  - we do not call js_LeaveTrace (so the argument is not the global object)
  - we try to read from dslots, which is NULL, so we crash.

So it seems we really are getting a property cache entry that tells us to read from a slot we don't have.

Comment 9

[David Mandelin [:dmandelin]]

I investigated the minidump further and found that obj, aobj, and obj2/pobj seem to be the same object (they are stored at esp+1c, esp+48, and esp+3c, respectively). I want to check this in some more minidumps--so far I checked another dump and they were all the same again. Assuming this is correct (which I think, but this stuff is pretty hard, so I'm not entirely sure), this narrows down causes a fair amount, because proto stuff is not in play.

I spent a little time thinking about how this could happen, but I didn't come up with anything right away. Here's one possibility I thought of that I think *doesn't* work ("work" defined as crash):

  1. create an object with 6 slots and a special getter for the property stored in slot 5.
  2. do a get on the object.
  3. the getter deletes the property in slot 5. dslots is no longer needed and is set to null.
  4. the property cache creates a cache entry listing slot 5.
  5. do another get: there is a property cache hit, we try to read slot 5 with null dslots and crash.

But, I think that step 4 can't happen because js_FillPropertyCache checks that the property is still part of the scope, and presumably after the deletion, it wouldn't be.

Ideas for next steps:

- Change all points that set dslots to NULL to set 'different' null values (0xdeadbeef, zero page addrs, etc) for 3.5.4 so we can see what is actually setting dslots to 0. If it's a finalizer, then it's probably a GC rooting issue. If it's FreeSlot, then it's probably something along the lines of what I sketched above. If it's a constructor, then it's probably some other property cache bustage.

- Also for 3.5.4, change the valid-slot check in js_FillPropertyCache to get a clearer picture of what's happening there. Maybe other instrumentation too.

- Dig into the crash reports again and try to see better when this stopped happening on trunk.

- More detailed code reading to try to find conditions under which dslots gets set to null with a property cache entry. This seems really hard to do manually, though.

- Survey the non-stub getters in 3.5.3 to see if anything suspicious turns up.

Comment 10

[David Mandelin [:dmandelin]]

Attachment: Crash frobulator patch

This patch makes dslots null into 9 different versions of null, depending on where it is set. This should change the crash addresses to be offset in a way that we can tell which code set dslots to NULL.

Comment 11

[Jeff Walden [:Waldo]]

That is the most epic patch I have ever seen.

Comment 12

[David Mandelin [:dmandelin]]

Attachment: Crash frobulator patch 2 (fix int type per Jeff)

Comment 13

[David Mandelin [:dmandelin]]

It seems that the bug is still present on trunk. Here is an example of a crash for which I have a minidump:

http://crash-stats.mozilla.com/report/index/4b04608f-457f-4586-9984-edd012090825

These crashes are also reported in the bugs marking blocking this one. Sadly, there doesn't seem to be a way to consistently repro, except for the Xmarks issue, which I haven't tried yet. 

The minidump definitely shows another |dslots is NULL| cause. It appears to be in the getprop property cache hit path (as before), although to be certain I would need to do some more heavy-duty disassembly. One interesting thing is that that in 3.6a1 and trunk versions of this crash, array_forEach/array_extra are always on the stack. So there could be a GC rooting bug there.

Comment 14

[David Mandelin [:dmandelin]]

Attachment: Crash patch for trunk

Now that I realize this bug or at least some close relative is happening on trunk, and generating crash reports daily, it makes better sense to land the crash patch on trunk and start getting data faster.

Comment 15

[Brendan Eich [:brendan]]

Comment on attachment 404967 [details] [diff] [review]
Crash frobulator patch 2 (fix int type per Jeff)

I'm a compleatist: manifest constant for 4096 and r=me.

/be

Comment 16

[Brendan Eich [:brendan]]

Comment on attachment 404976 [details] [diff] [review]
Crash patch for trunk

Ditto.

/be

Comment 17

[David Mandelin [:dmandelin]]

I got 2 crashreports in today for this bug with the new patch:

http://crash-stats.mozilla.com/report/index/5a2ca4ea-091f-403d-a557-b51ac2091008
http://crash-stats.mozilla.com/report/index/8f00d9b4-fa3e-441d-bef7-7075f2091008

Both have a crash address of 0x500. This means that dslots was set by JSObject::init. Thus, the bug is that we get a property cache hit with a slot >= 5 where dslots was nulled by JSObject::init. Some possible causes for this:

1. We create an object, set a non-null dslots, then create a property cache entry, then call ::init on the object again without setting the scope (obj->map). Calling ::init without setting the scope seems impossible from my reading of the code.

2. We create an object with a map that indicates slot 5 is available but never set dslots. If there is an existing prop cache entry with the same shape as this map, then we can hit and crash.

I notice that js_NewObjectWithGivenProto can use a map (scope) returned by the class. It doesn't otherwise validate that map, so if a class is handing out bad maps, that seems like that could do this.

3. We create an object, then create a prop cache entry for slot 5, even though there is none. If we hit that entry later, we crash.

I'm testing a new patch that will help gather more info. Mostly, it just adds new null pointer values to disambiguate which site init was called from. I also record whether we are using a non-native ops struct (and thus class-provided scope, as in (2) above) in js_NewObjectWithGivenProto. Finally, I set a bit if case (3) happens (although I don't think it catches all possible kinds of case (3) situation, but that would be hard).

Comment 18

[David Mandelin [:dmandelin]]

Attachment: Crash modifier 2

This collects the additional info I described in the previous comment.

Comment 19

[Daniel Holbert [:dholbert]]

Landed "Crash modifier 2" on behalf of dmandelin:
 http://hg.mozilla.org/mozilla-central/rev/f31e1dc13387

Comment 20

[David Mandelin [:dmandelin]]

The 10/09 build has the 'crash modifier 2' instrumentation, but no one has crashed in js_Interpret with that build yet. It looks like for this frequency of bug and users' update habits, the first crash for a new build usually happens in the first day or two. I'll keep watching.

Comment 21

[David Mandelin [:dmandelin]]

We got two crashes with the 10/09 instrumentation patch yesterday. Both were on Mac. I'm not sure if that means anything--hopefully not. The crash addresses start with 6, which means JSObject::init was called from js_NewObjectWithGivenProto, and also that |OPS_IS_NATIVE(ops) == true|, so the scope is being initialized by InitScopeForObject. The 128 bit is clear, which means that js_FillPropertyCache is *not* creating an entry for slot 5+ with an object with null dslots (which would be very bad, and I expected was not happening).

I'll have to think about this more when my brain is actually working, but for now, I can summarize the basic findings like this:

  - we crash because we get a prop cache hit for slot 5 when accessing a property on an object with null dslots
  - dslots is null because it was set to null in js_NewObjectForGivenProto as a native object, so the object was created with <=2 properties and never got any more properties than that

So it's starting to look like a fault in the scope creation/sharing code that makes 2 objects end up with the same scope/shape even though one has null dslots and the other has non-null dslots. (In bug 510996, we have localized what looks like one of these crashes in some nsSessionStore.js code that involves a standard native object, but also works closely with non-native objects, so there is a small chance of some kind of confusion there.)

Comment 22

[(not currently active) Ted Mielczarek]

Just a note: if you ever intend to land the instrumentation stuff on branch, the "crash address" field is only useful on Win32 there. On Mac/Linux branch builds, it's always the instruction pointer (that fix only landed on trunk currently).

Comment 23

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Can we backport that fix to 1.9.2 at least?  It's extremely valuable data.

Comment 24

[(not currently active) Ted Mielczarek]

We can do that. Filed bug 522682 on that. I had thought about that previously but it slipped my mind.

Comment 25

[Jesse Ruderman]

dmandelin suspects this might be related to bug 522817, which has something of a testcase.

Comment 26

[Brendan Eich [:brendan]]

(In reply to comment #25)
> dmandelin suspects this might be related to bug 522817, which has something of
> a testcase.

Turns out bug 522817 was too new. There could be a similar get-slot-before-shape-guard bug, but I don't see it. Or as dmandelin points out, we could easily be chasing another problem of the kind discussed in bug 508711.

/be

Comment 27

[David Mandelin [:dmandelin]]

Attachment: Crash modifier 3 (test for scope sharing)

This is to test if the objects on which we are crashing have shared empty scopes taken from their prototypes. If they don't, then we know to look elsewhere, and if they do, we know to look harder at how scope sharing works.

Comment 28

[David Mandelin [:dmandelin]]

Attachment: Crash modifier 4 (test for shape overflow bit in crashing object)

This is to test if the shape overflow bit is set on the crashing object. It's an easy thing to test, not super likely to be the problem, but it's possible.

Comment 29

[David Mandelin [:dmandelin]]

Crash modifier 4 landed to m-c as d238880d14a0. This should start collecting data with the 10/27 nightly build.

Comment 30

[Tony Chung [:tchung]]

Crashed on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091027 Namoroka/3.6b2pre

I'm reproducing this crash 100% by deleting comments on my facebook wall.  The repro steps is to delete 6 in a row, and it will crash @js_interpret on the 6th comment.  

http://crash-stats.mozilla.com/report/index/74c56637-483f-4048-934d-248542091026

Frame  	Module  	Signature [Expand]  	Source
0 	libmozjs.dylib 	js_Interpret 	js/src/jsops.cpp:1505
1 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1368
2 	libmozjs.dylib 	array_extra 	js/src/jsarray.cpp:3193
3 	libmozjs.dylib 	js_Interpret 	js/src/jsops.cpp:2208
4 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1368
5 	libmozjs.dylib 	array_extra 	js/src/jsarray.cpp:3193
6 	libmozjs.dylib 	js_Interpret 	js/src/jsops.cpp:2208
7 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1368
8 	libmozjs.dylib 	js_fun_call 	js/src/jsfun.cpp:1948
9 	libmozjs.dylib 	js_Interpret 	js/src/jsops.cpp:2208
10 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1368
11 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1671
12 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
13 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93
14 	XUL 	PrepareAndDispatch 	
15 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:435
16 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:519
17 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:527
18 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:180
19 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:121
20 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:413
21 	CoreFoundation 	CFRunLoopRunSpecific 	
22 	CoreFoundation 	CFRunLoopRunInMode 	
23 	HIToolbox 	RunCurrentEventLoopInMode 	
24 	HIToolbox 	ReceiveNextEventCommon 	
25 	HIToolbox 	BlockUntilNextEventMatchingListInMode 	
26 	AppKit 	_DPSNextEvent 	
27 	AppKit 	-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 	
28 	AppKit 	-[NSApplication run] 	
29 	XUL 	nsAppShell::Run 	widget/src/cocoa/nsAppShell.mm:766
30 	XUL 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:182
31 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3481
32 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:156
33 	firefox-bin 	firefox-bin@0x1541 	
34 	firefox-bin 	firefox-bin@0x1468 	
35 		@0x2

Comment 31

[David Mandelin [:dmandelin]]

(In reply to comment #30)
> Crashed on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.2b2pre) Gecko/20091027 Namoroka/3.6b2pre
> 
> I'm reproducing this crash 100% by deleting comments on my facebook wall.  The
> repro steps is to delete 6 in a row, and it will crash @js_interpret on the 6th
> comment.  

A possible fix for that went into the tracemonkey repo yesterday, so it should be in today's nightly. Hopefully it will make it into m-c today but it never hurts to get an early test of whether it's fixed.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-tracemonkey/

Comment 32

[Damon Sicore (:damons)]

Can we get a percentage of crashes that we think this fixes?

Comment 33

[David Mandelin [:dmandelin]]

(In reply to comment #32)
> Can we get a percentage of crashes that we think this fixes?

Based on a sample of 2 weeks worth of recent reports:

1.9.1:  40%  (with a long tail)
1.9.2:  90%
trunk:  50%  (with one other major bug that now accounts for almost all crashes)

Comment 34

[Tony Chung [:tchung]]

I'm still reproducing this crash 100%, this time on a different profile running trunk.  

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091102 Minefield/3.7a1pre

David, has your patch landed on trunk yet?

Comment 35

[Tony Chung [:tchung]]

(In reply to comment #34)
> I'm still reproducing this crash 100%, this time on a different profile running
> trunk.  
> 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre)
> Gecko/20091102 Minefield/3.7a1pre
> 
> David, has your patch landed on trunk yet?

for reference:

http://crash-stats.mozilla.com/report/index/8a5e2d38-0a1a-4f6d-b2a2-4bd572091103

Comment 36

[David Mandelin [:dmandelin]]

(In reply to comment #35)
> (In reply to comment #34)
> > I'm still reproducing this crash 100%, this time on a different profile running
> > trunk.  
> > 
> > Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre)
> > Gecko/20091102 Minefield/3.7a1pre
> > 
> > David, has your patch landed on trunk yet?
> 
> for reference:
> 
> http://crash-stats.mozilla.com/report/index/8a5e2d38-0a1a-4f6d-b2a2-4bd572091103

That crash is actually bug 525028. But this could be really good because that's another trunk topcrash and we don't have a test case for that or a candidate fix.

Comment 37

[David Mandelin [:dmandelin]]

Attachment: Remove crash modifier code

This strips out the debugging instrumentation added by the 4 crash modifier patches, which is no longer needed.

Comment 38

[Luke Wagner [:luke]]

Comment on attachment 411313 [details] [diff] [review]
Remove crash modifier code

Goodnight, sweet prince.

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

We're seeing a lot of @js_Interpret in the topcrash list for 1.9.2 betas, so nominating this for blocking.

Comment 40

[David Mandelin [:dmandelin]]

The fix for this is over in bug 524743, which is already marked blocking 1.9.2. Maybe this bug should just be dup'd to that at this point?

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

David: I'm not comfortable marking this as a dupe with my limited knowledge, but if the issue is fixed on all trees (TM, MC and 192) by bug 524743 I'm happy with this being duplicated to that, sure.

Marking as blocking so that if this gets re-opened we pick up the flag.

Comment 42

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Yeah, that's the case.