Closed Bug 595975 Opened 10 years ago Closed 7 years ago

Crash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]

Categories

(Core :: JavaScript Engine, defect, critical)

defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: marcia, Assigned: dmandelin)

References

(Blocks 1 open bug)

Details

(Keywords: crash, sec-moderate, Whiteboard: [sg:moderate] elusive)

Crash Data

Attachments

(2 files, 1 obsolete file)

Seen while running Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100913 Firefox/4.0b6pre. http://tinyurl.com/3946qka links to crashes which are Mac and Linux only so far. Currently the #62 top crash on the trunk. Crashes started showing up in crash stats using the 2010090900 build.

STR:
1. Load the Peacekeeper URL and begin running the tests.
2. Crash: 

http://crash-stats.mozilla.com/report/index/7cebacdc-59cf-4544-b737-cb72d2100913

Frame  	Module  	Signature [Expand]  	Source
0 	XUL 	js::PropertyTable::search 	js/src/jsscope.cpp:302
1 	XUL 	js_LookupPropertyWithFlags 	js/src/jsscope.h:849
2 	XUL 	js_GetPropertyHelper 	js/src/jsobj.cpp:4780
3 	XUL 	js_GetProperty 	js/src/jsobj.cpp:4864
4 	XUL 	js::mjit::ic::GetProp 	js/src/jsobj.h:1023
5 		@0x24ebd32d 	
6 	XUL 	js::mjit::JaegerShot 	js/src/methodjit/MethodJIT.cpp:760
7 	XUL 	js::Execute 	js/src/jsinterp.cpp:465
8 	XUL 	JS_EvaluateUCScriptForPrincipals 	js/src/jsapi.cpp:4674
9 	XUL 	nsJSContext::EvaluateString 	dom/base/nsJSEnvironment.cpp:1749
10 	XUL 	nsGlobalWindow::RunTimeout 	dom/base/nsGlobalWindow.cpp:8573
11 	XUL 	nsGlobalWindow::TimerCallback 	dom/base/nsGlobalWindow.cpp:8933
12 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:425
13 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
14 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
15 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:200
16 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:131
17 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:394
18 	CoreFoundation 	CFRunLoopRunSpecific 	
19 	CoreFoundation 	CFRunLoopRunInMode 	
20 	HIToolbox 	RunCurrentEventLoopInMode 	
21 	HIToolbox 	ReceiveNextEventCommon 	
22 	HIToolbox 	BlockUntilNextEventMatchingListInMode 	
23 	AppKit 	_DPSNextEvent 	
24 	AppKit 	-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 	
25 	AppKit 	-[NSApplication run] 	
26 	XUL 	nsAppShell::Run 	widget/src/cocoa/nsAppShell.mm:747
27 	XUL 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:191
28 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3665
29 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:158
30 	firefox-bin 	firefox-bin@0xbe5 	
31 		@0x1
This may be a duplicate of the other Peacekeeper bugs, in particular bug 595604.
crashes started showing up on sept 9, in builds from that mornin g

date     tl crashes at, count build, count build, ...
         js::PropertyTable::search

20100906
20100907
20100908
20100909 3 ,3 4.0b6pre^\2010090804
20100910 9 ,6 4.0b6pre^\2010091003 ,3 4.0b6pre^\2010090903
20100911 1 ,1 4.0b6pre^\2010091103
20100912 20 ,1 4.0b6pre^\2010091103 ,18 4.0b6pre^\2010091203 ,1 4.0b6pre2010091204
Depends on: 595604
One Mac crash still persists after bug 595604 was checked in, it has a build id of
20100918030703.

There are also a handful of Windows crashes that have a similar stack: [@ js::PropertyTable::search(int, bool) ]
Sorry, should have included that report ID in the previous comment: https://crash-stats.mozilla.com/report/index/a5e53ef6-d473-466a-8f48-39f242100920
Saw this when switching a tab:
bp-b84f1f39-156d-45a8-9656-475c22101110
I can reproduce this consistently using my nightly, and it started happening right after I installed BarTab (disabling extension compatibility). I have about 40 tabs open, which is why I wanted BarTab. It installs fine, loads, a minute or so later after loading everything, it crashes.
I don't see this anymore in the latest TraceMonkey nightly, where previously I could reproduce it consistently.
I just got this. I think it's related to BarTab in some interesting way too, and happened when I connected to a new network. (which of these are related, I don't know)

Here's my entry:
http://crash-stats.mozilla.com/report/index/bp-c3595ad7-5efe-452b-900e-edb612101130
It's reproducible with BarTab, but today it happened without using it: bp-50e90293-c4cd-4496-a5cc-838fb2101130
Duplicate of this bug: 615492
blocking2.0: --- → ?
OS: Mac OS X → All
Hardware: x86 → All
Summary: Crash in [@ js::PropertyTable::search ] → Crash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]
This WFM in TM nightly of Dec 16. I installed BarTab, then ran the Peacekeeper benchmarks.
Got this one while shutting down Minefield nightly, and shutting down xp.
Didn't get to add comments in crash reporter before win took it down.
No BarTab, btw.
http://crash-stats.mozilla.com/report/index/6f1dabe0-fff2-484f-818a-dfdfc2101221
OK, this looks like a legit topcrash, so I'm morphing it to that. The signature is old but it started becoming more common in nightly builds on/after Nov 23. I think it needs minidump attention.
blocking2.0: ? → betaN+
No longer depends on: 595604
Summary: Crash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ] → topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]
I found that most of the reports are for crashes at this spot:

Shape **
PropertyTable::search(jsid id, bool adding)
{
    JSHashNumber hash0, hash1, hash2;
    int sizeLog2;
    Shape *stored, *shape, **spp, **firstRemoved;
    uint32 sizeMask;

    JS_ASSERT(entries);
    JS_ASSERT(!JSID_IS_VOID(id));

    /* Compute the primary hash address. */
    METER(hashes);
    hash0 = HASH0(id);
    hash1 = HASH1(hash0, hashShift);
    // CRASH accessing hashShift

hashShift is the first field of PropertyTable, so the immediate cause of the crash is that |this| is a bad pointer. There is a lot of inlining on the paths in the crash stacks, but we are generally called via js_GetProperty, so I think we go through js_LookupProperty to nativeLookup to nativeSearch to Shape::search, and then here. The PropertyTable value is |obj->lastProp->table|,
where |obj| is the original argument to js_GetProperty.

Because we don't see a high frequency of crashes higher up in the stack dereferencing |lastProp|, it seems likely that the problem is that |lastProp->table| is a bad pointer, i.e., |Shape JSObject::lastProp| is somehow bogus. Note that we also have a fairly high frequency of GC crashes tracing |Shape::id|, another case of apparent bad Shape values. 

Ideas for possible causes:

1. We have objects that use the default property getter, but really aren't native objects. I'm not sure how this would happen or if it is a likely cause.

2. We free shapes that are in use and then write junk over them. I think they live in arenas, so I wouldn't expect random junk to get written over them, but maybe it can happen somehow.

3. Some other place writes over memory.

As a first step, I'd like to bring back the Shape values that we crash on to see if they look generally corrupted or what.
Assignee: general → dmandelin
Status: NEW → ASSIGNED
Attachment #499952 - Flags: review?(wmccloskey)
Comment on attachment 499952 [details] [diff] [review]
Instrumentation patch: save Shape in blackbox

r+ with no *0=0.
Attachment #499952 - Flags: review?(wmccloskey) → review+
Attachment #499952 - Attachment is obsolete: true
Attachment #499954 - Flags: review?(wmccloskey)
Attachment #499954 - Flags: review?(wmccloskey) → review+
We analyzed 0e6576ca-ed57-4d06-9571-41f472101228, which has data from the diagnostic patch. Data values of interest:

  JSObject *obj     0x06af90e0

  Shape *obj->lastProp fields
      shape         0x06af9150        // maybe a JSObject *?
      slotSpan      0x10960fe0        // clearly garbage
      table                  1        // clearly garbage
      id               0x3224e
      getter        0x0e5dcb40
      setter        0x06af6078
      slot          0x06af6028
      attrs               0x20
      flags               0xcb
      shortid            0xe5d
      parent                 2
      kids/listp    0x06af9140

None of this looks reasonable, so either this memory never was initialized as a Shape, or it has been written over, and not to store a new Shape in the exact same space. This is also not JSObjectMap::sharedNonNative, because that one is { 0xffffffff, 0 }. Current guesses:

1. A new shape gets allocated at some offset, and writes over this one, with the fields in different positions. This is based on the observation that '1' and '2' are plausible values for some of the fields, like slotSpan and slot.

2. Something writes all over the shape for no reason.

Next I'm going to try to adding markers to the start and end of the Shape struct so that we can see if there are offset shapes in there. Also, we should bring back the Object contents--maybe the clasp or some other such member will be a clue.
Attachment #500115 - Flags: review?(wmccloskey)
Attachment #500115 - Flags: review?(wmccloskey) → review+
(In reply to comment #24)
> Diagnotic 2 is in:
> 
> http://hg.mozilla.org/mozilla-central//rev/c35a4e6ea3ca

This caused a significant number of performance regressions reported to mozilla.dev.tree-management (on SunSpider and a bunch of different Dromaeo tests).

I'm presuming this patch is temporary and will be backed out at some point?
(In reply to comment #25)
> (In reply to comment #24)
> > Diagnotic 2 is in:
> > 
> > http://hg.mozilla.org/mozilla-central//rev/c35a4e6ea3ca
> 
> This caused a significant number of performance regressions reported to
> mozilla.dev.tree-management (on SunSpider and a bunch of different Dromaeo
> tests).
> 
> I'm presuming this patch is temporary and will be backed out at some point?

Yes. We haven't gotten any data back from it yet, but these happen 5-10 times per day so we should be ready to back it out later today. Thanks for letting me know it's an issue.
FWIW, diagnostic 2 added tons of build warning spew of the following form:
{
In file included from ../../../mozilla/js/src/jsobjinlines.h:61,
                 from ../../../mozilla/js/src/jsregexp.cpp:59:
> jsscope.h: In constructor ‘js::Shape::Shape(jsid, JSBool (*)(JSContext*, JSObject*, jsid, js::Value*), JSBool (*)(JSContext*, JSObject*, jsid, js::Value*), uint32, uintN, uintN, intN, uint32, uint32)’:
> jsscope.h:344: warning: ‘js::Shape::parent’ will be initialized after
> jsscope.h:295: warning:   ‘uint32 js::Shape::marker1’
> jsscopeinlines.h:170: warning:   when initialized here
> jsscope.h: In constructor ‘js::Shape::Shape(JSContext*, js::Class*)’:
> jsscope.h:344: warning: ‘js::Shape::parent’ will be initialized after
> jsscope.h:295: warning:   ‘uint32 js::Shape::marker1’
> jsscopeinlines.h:185: warning:   when initialized here
}

(This gets spammed for every .cpp file to directly or indirectly include jsscopeinlines.h, which looks like quite a lot of .cpp files judging by my build-spew today.)

Was going to look into fixing it, but it sounds like it's getting backed out soon anyway, per comment 26.
Diagnostic 2 backed out:

http://hg.mozilla.org/mozilla-central/rev/2571397d53be

Diagnostic 1 backed out:

http://hg.mozilla.org/mozilla-central/rev/37068ce988b9

Thanks for bearing with us on the temporary perf regressions and annoying warnings. We got the data we needed.
Diagnostic 2 gave us pretty interesting data, but unfortunately showed that this is basically a GC issue and will likely be incredibly hard to fix, so I am unblocking for now.

Looking at 3 minidumps from today's build, we found:

- The saved |Shape| contents were total garbage, as before, with none of the 'markers' seen. This means the problem is *not* writing shape data at an offset, which seemed unlikely anyway.

- We saw some jsvals in the |Shape| data for some dumps, mostly undefined values.

- The |Object| contents seemed fine, except for the Shape pointer, which is obviously bogus.

- The Shape pointer (obj->lastProp) in each case had a value very near the Object pointer. In fact, it was either 0x28 or 0x38 greater than the Object pointer. Thus, obj->lastProp actually points into an Object allocation arena.

- The first word of the Shape contents also points to something close to its own address (again, 0x28 or 0x38 past it). This would be the freelist pointer if this space is a freed object.

One possibility would be that somehow obj->lastProp gets set to a pointer that is really a freed Object. But Bill pointed out this is also consistent with the Object being freed, where only the first word (FreeCell::link *and* JSObject::lastProp) is overwritten with the free-list pointer. This seems much more likely. I.e., a live object has been freed.

This scenario could also explain some of our other GC bugs. We have crashes while trying to mark Shapes. If a live JSObject is freed, then we could try to mark it at a later point and would likely crash marking its Shape, because that would be a pointer to bogus data.
blocking2.0: betaN+ → .x
B8 crash data shows a pretty heavy correlation to Ghostery extension, as well as Adblock Plus.

EXC_BAD_ACCESS (-1)

79% (15/19) vs.   5% (40/851) firefox@ghostery.com (Ghostery, https://addons.mozilla.org/addon/9609)
68% (13/19) vs.  33% (279/851) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
26% (5/19) vs.   5% (46/851) {3d7eb24f-2740-49df-8937-200b1cc08f8a} (Flashblock, https://addons.mozilla.org/addon/433)
32% (6/19) vs.  12% (99/851) {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389} (Download Statusbar, https://addons.mozilla.org/addon/26)
32% (6/19) vs.  12% (100/851) compatibility@addons.mozilla.org
21% (4/19) vs.   2% (15/851) {37fa1426-b82d-11db-8314-0800200c9a66} (WebMail Notifier, https://addons.mozilla.org/addon/4490)
21% (4/19) vs.   5% (44/851) {a0d7ccb3-214d-498b-b4aa-0e8fda9a7bf7} (WOT, https://addons.mozilla.org/addon/3456)
21% (4/19) vs.   6% (48/851) {73a6fe31-595d-460b-a920-fcc0f8843232} (NoScript, https://addons.mozilla.org/addon/722)
16% (3/19) vs.   2% (19/851) {EF522540-89F5-46b9-B6FE-1829E2B572C6} (GooglePreview, https://addons.mozilla.org/addon/189)
16% (3/19) vs.   2% (20/851) https-everywhere@eff.org
21% (4/19) vs.   8% (67/851) firefox4@1password.com
21% (4/19) vs.  10% (87/851) foxmarks@kei.com (Xmarks (formerly Foxmarks), https://addons.mozilla.org/addon/2410)
11% (2/19) vs.   0% (3/851) {6005d9b1-d115-485a-a92a-3f6453ca3fe2}
11% (2/19) vs.   1% (8/851) feedly@devhd (Feedly, https://addons.mozilla.org/addon/8538)
11% (2/19) vs.   1% (10/851) adblockpopups@jessehakanen.net
11% (2/19) vs.   1% (11/851) {d40f5e7b-d2cf-4856-b441-cc613eeffbe3} (BetterPrivacy, https://addons.mozilla.org/addon/6623)
16% (3/19) vs.   7% (57/851) {AE93811A-5C9A-4d34-8462-F7B864FC4696} (StumbleUpon, https://addons.mozilla.org/addon/138)
11% (2/19) vs.   2% (13/851) en-US@dictionaries.addons.mozilla.org (United States English Dictionary, https://addons.mozilla.org/addon/3497)
11% (2/19) vs.   2% (16/851) {6AC85730-7D0F-4de0-B3FA-21142DD85326} (ColorZilla, https://addons.mozilla.org/addon/271)
11% (2/19) vs.   2% (16/851) ffshare@mozilla.org
11% (2/19) vs.   2% (17/851) foxyproxy@eric.h.jung (FoxyProxy, https://addons.mozilla.org/addon/2464)
26% (5/19) vs.  18% (150/851) firebug@software.joehewitt.com (Firebug, https://addons.mozilla.org/addon/1843)
11% (2/19) vs.   3% (27/851) {e3f6c2cc-d8db-498c-af6c-499fb211db97}
11% (2/19) vs.   4% (31/851) {e4a8a97b-f2ed-450b-b12d-ee082ba24781} (Greasemonkey, https://addons.mozilla.org/addon/748)
11% (2/19) vs.   5% (40/851) isreaditlater@ideashower.com (Read It Later, https://addons.mozilla.org/addon/7661)
16% (3/19) vs.  10% (87/851) {340c2bbc-ce74-4362-90b5-7c26312808ef} (Mozilla Labs - Weave Sync, https://addons.mozilla.org/addon/10868)
95% (18/19) vs.  89% (760/851) testpilot@labs.mozilla.com (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)
5% (1/19) vs.   0% (1/851) hashcolouredtabs@bristol.ac.uk (HashColouredTabs+, https://addons.mozilla.org/addon/4279)
5% (1/19) vs.   0% (1/851) tabsup@torun.pl
5% (1/19) vs.   0% (1/851) personasexpression@eddiescorpse.private
5% (1/19) vs.   0% (1/851) {fc6339b8-9581-4fc7-b824-dffcb091fcb7} (SomethingAwful Last Read Enhancement, https://addons.mozilla.org/addon/8398)
5% (1/19) vs.   0% (1/851) {9e1d7c80-43d1-11db-b0de-0800200c9a66}
5% (1/19) vs.   0% (1/851) masspasswordreset@johnathan.nightingale (Mass Password Reset, https://addons.mozilla.org/addon/9652)
5% (1/19) vs.   0% (1/851) jid0-1CPla5gMJuPNwiGgBF5bltkE3o8@jetpack
5% (1/19) vs.   0% (1/851) bg-BG@dictionaries.addons.mozilla.org (Bulgarian Dictionary, https://addons.mozilla.org/addon/3623)
5% (1/19) vs.   0% (1/851) {317B5128-0B0B-49b2-B2DB-1E7560E16C74} (SeoQuake SEO extension, https://addons.mozilla.org/addon/3036)
5% (1/19) vs.   0% (1/851) PrivacyPlus@PeterOlayev.com (Privacy +, https://addons.mozilla.org/addon/14217)
5% (1/19) vs.   0% (1/851) {1d682819-bef2-4a75-8ffa-adf3733f5557} (Instaright!, https://addons.mozilla.org/addon/13317)
5% (1/19) vs.   0% (1/851) {723AAF16-AF1F-4404-A5D7-0BFE39766605} (Copy Plain Text, https://addons.mozilla.org/addon/134)
5% (1/19) vs.   0% (1/851) enter.selects@agadak.net (Enter Selects, https://addons.mozilla.org/addon/7423)
5% (1/19) vs.   0% (1/851) {3892FE4C-6DCB-4669-9D01-E23BB9FB61FB} (MyWords, https://addons.mozilla.org/addon/7496)
5% (1/19) vs.   0% (1/851) wappalyzer@crunchlabz.com (Wappalyzer, https://addons.mozilla.org/addon/10229)
5% (1/19) vs.   0% (1/851) browserlab@adobe.com
5% (1/19) vs.   0% (1/851) tinyurl.addon@fast-chat.co.uk (TinyURL Generator, https://addons.mozilla.org/addon/10586)
5% (1/19) vs.   0% (2/851) checkplaces@andyhalford.com (CheckPlaces, https://addons.mozilla.org/addon/10897)
5% (1/19) vs.   0% (2/851) {992791ee-61dc-7b98-a8fd-dc49b7deeee9} (TryAgain, https://addons.mozilla.org/addon/2462)
5% (1/19) vs.   0% (2/851) nosquint@urandom.ca (NoSquint, https://addons.mozilla.org/addon/2592)
5% (1/19) vs.   0% (2/851) {6F0976E6-26F3-4AFE-BBEC-9E99E27E4DF3} (Fire.fm, https://addons.mozilla.org/addon/7684)
5% (1/19) vs.   0% (2/851) {d57c9ff1-6389-48fc-b770-f78bd89b6e8a} (SearchStatus, https://addons.mozilla.org/addon/321)
5% (1/19) vs.   0% (2/851) rankchecker@seobook.com
5% (1/19) vs.   0% (2/851) {F807FACD-E46A-4793-B345-D58CB177673C} (ScribeFire Blog Editor, https://addons.mozilla.org/addon/1730)
It is #7 top crasher on Mac OS X in 4.0b8 for the last week.
Depends on: CVE-2011-0057
Group: core-security
hiding until we are sure this is unrelated to bug 626631 or have a fix there.
Whiteboard: [sg:critical?]
I added to the link to the Peacekeeper benchmark in the URL field for reference. I cannot crash using FF Beta 9 running that URL.
bent has a setup that reliably triggers this crash. We should consider blocking on this and fixing it. What is the volume here?
It's 1/day in nightlies, #30 on trunk. I don't want to block on it, though--there are more urgent things to take care of in the next few days.

Is the setup a test case that could post here, or something stranger?
(In reply to comment #35)
> It's 1/day in nightlies, #30 on trunk. I don't want to block on it,
> though--there are more urgent things to take care of in the next few days.
> 

If both of the signatures in the title are still valid for this bug I'm seeing different numbers.

js::PropertyTable::search is pretty   low volume with a rough daily volume running 17-30 crashes per day across all beta users

         js::PropertyTable::search

date     total    breakdown by build
         crashes  count build, count build, ...

20110126 29  	18 4.0b92011011019, 
        		5 4.0b102011012116, 	2 4.0b82010121416, 
        		1 4.0b92011011215, 	1 4.0b72010110413, 
        		1 4.0b10pre2011012503, 	1 4.0b10pre2011012403, 

 js::PropertyTable::search.int,.bool. look much higher to me recently hitting 463 crashes per day across all betas, and making it #5 top crash on beta9.

date     total    breakdown by build
         crashes  count build, count build, ...


20110124 463  	430 4.0b92011011019, 
        		14 4.0b82010121417, 	14 4.0b72010110414, 
        		2 4.0b10pre2011012115, 	1 4.0b10pre2011012403, 
        		1 4.0b10pre2011012103, 	1 4.0b10pre2011011903, 

more of these can be seen at

http://crash-stats.mozilla.com/report/list?signature=js::PropertyTable::search%28int,%20bool%29

These numbers plus the fact that this is sg:critical? ought to put in in the running to get fixed soon.
I second #36. This looks scary and wants a fix. I vote for at least softblocker status since we have a way to reproduce now.
any status?
(In reply to comment #38)
> any status?

Bug 569422 might help this.
Depends on: 569422
Summary: topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ] → topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ] mainly with Kikin (Windows) or Firebug (Mac)
blocking2.0: .x+ → -
status2.0: --- → wanted
Blocks: 646745
Whiteboard: [sg:critical?] → [sg:critical?][work ongoing in bug 637304]
Summary: topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ] mainly with Kikin (Windows) or Firebug (Mac) → topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]
Whiteboard: [sg:critical?][work ongoing in bug 637304] → [sg:needinfo]
Crash Signature: [@ js::PropertyTable::search(int, bool) ] [@ js::PropertyTable::search ]
This signature is still popular (2500+/week) and still happening on versions 4 through 10. There appear to be multiple different crashes here but at least some of these crashes look exploitable (ACCESS_VIOLATION_WRITE and ACCESS_VIOLATION_EXEC). For the moment the overall risk seems more "moderate", but there's definitely an sg:critical (or two?) lurking in here.
Crash Signature: [@ js::PropertyTable::search(int, bool) ] [@ js::PropertyTable::search ] → [@ js::PropertyTable::search(int, bool) ] [@ js::PropertyTable::search ]
Whiteboard: [sg:needinfo] → [sg:moderate] elusive
It's #13 top crasher in 9.0b2 while it's only #76 in 8.0, #125 in 10.0a2, and #249 in 11.0a1.
The spike appeared around 9.0a2/20111009 or 9.0a2/20111010:
https://crash-stats.mozilla.com/report/list?range_value=30&range_unit=days&date=2011-10-30&signature=js%3A%3APropertyTable%3A%3Asearch%28int%2C%20bool%29&version=Firefox%3A9.0a2
It seems to be correlated to new users in the Aurora sample group:
2011-10-10 	92,989 
2011-10-09 	77,536
2011-10-08 	74,934
It's #2 top crasher on Mac OS X and #17 top crasher on Windows in 9.0b3.

According to some comments, it's related to Firebug:
"Firebug. :( (Clicked the inspect element icon)"
"Using Firebug"
It's #18 top browser crasher in 9.0.1 on Windows and #2 on Mac OS X only.
Both are correlated to Forecastfox.

* Windows correlations per add-on:
  js::PropertyTable::search(int, bool)|EXCEPTION_ACCESS_VIOLATION_READ (323 crashes)
68% (219/323) vs.   2% (830/51702) {0538E3E3-7E9B-4d49-8831-A227C80A7AD3} (Forecastfox, https://addons.mozilla.org/addon/398)

* Mac correlations per add-on:
  js::PropertyTable::search|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (20 crashes)
     75% (15/20) vs.   7% (56/834) {0538E3E3-7E9B-4d49-8831-A227C80A7AD3} (Forecastfox, https://addons.mozilla.org/addon/398)

  js::PropertyTable::search|EXC_BAD_ACCESS / 0x0000000d (14 crashes)
     64% (9/14) vs.   7% (56/834) {0538E3E3-7E9B-4d49-8831-A227C80A7AD3} (Forecastfox, https://addons.mozilla.org/addon/398)
I don't think this is high enough volume to warrant the top crash keyword now - at #66 on 12, #57 on 13b3 and #124 on 14a2.
No longer blocks: 646745
No longer depends on: 569422, CVE-2011-0057
Keywords: topcrash
Blocks: 646745
Depends on: 569422, CVE-2011-0057
Summary: topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ] → Crash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]
Closing this as WFM. Peacekeeper no longer crashes, this signature is no longer a topcrash and there's been no activity for years.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.