Closed
Bug 595975
Opened 14 years ago
Closed 11 years ago
Crash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: marcia, Assigned: dmandelin)
References
Details
(Keywords: crash, sec-moderate, Whiteboard: [sg:moderate] elusive)
Crash Data
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•14 years ago
|
||
This may be a duplicate of the other Peacekeeper bugs, in particular bug 595604.
Comment 2•14 years ago
|
||
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
Comment 3•14 years ago
|
||
(In reply to comment #1)
> This may be a duplicate of the other Peacekeeper bugs, in particular bug
> 595604.
could be
urls look like
new mo betta urls for testing
2 http://www-auth.sdstate.edu/hr/index.cfm?cs_pgIsInLView=1
2 http://www-auth.sdstate.edu/hr/benefits.cfm
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.9622152925421189
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.9558554133433305
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.9173472483698032
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.7805732434025003
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.6839867766437713
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.4962706615589515
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.44607481964383866
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.23397921801223331
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.2232161427343159
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.12057353267677695
1 http://service.futuremark.com/peacekeeper/runTest.action?_=0.06707987546513272
os breakdown
js::PropertyTable::searchTotal 17
Mac10.6 0.47
Lin2.4 0.53
watch to see if these go away now that a fix for bug 595604 landed yesterday.
I saw this while editing text in the text field at http://benjamin.smedbergs.us/weekly-updates.fcgi/ (Mac 32-bit 2010-09-18)
http://crash-stats.mozilla.com/report/index/bp-a5e53ef6-d473-466a-8f48-39f242100920
Reporter | ||
Comment 5•14 years ago
|
||
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) ]
Reporter | ||
Comment 6•14 years ago
|
||
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
Comment 8•14 years ago
|
||
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.
Comment 9•14 years ago
|
||
I don't see this anymore in the latest TraceMonkey nightly, where previously I could reproduce it consistently.
Comment 10•14 years ago
|
||
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
Comment 11•14 years ago
|
||
It's reproducible with BarTab, but today it happened without using it: bp-50e90293-c4cd-4496-a5cc-838fb2101130
Updated•14 years ago
|
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 ]
Assignee | ||
Comment 13•14 years ago
|
||
This WFM in TM nightly of Dec 16. I installed BarTab, then ran the Peacekeeper benchmarks.
Comment 14•14 years ago
|
||
This crash signature still exists in the latest nightly.
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b9pre&platform=windows&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=js%3A%3APropertyTable%3A%3Asearch%28int%2C%20bool%29
Comment 15•14 years ago
|
||
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
Assignee | ||
Comment 16•14 years ago
|
||
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 ]
Assignee | ||
Comment 17•14 years ago
|
||
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 | ||
Comment 18•14 years ago
|
||
Comment on attachment 499952 [details] [diff] [review]
Instrumentation patch: save Shape in blackbox
r+ with no *0=0.
Attachment #499952 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 20•14 years ago
|
||
Attachment #499952 -
Attachment is obsolete: true
Attachment #499954 -
Flags: review?(wmccloskey)
Attachment #499954 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 21•14 years ago
|
||
Diagnostic patch:
http://hg.mozilla.org/mozilla-central//rev/e5e50e5a2816
Assignee | ||
Comment 22•14 years ago
|
||
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.
Assignee | ||
Comment 23•14 years ago
|
||
Attachment #500115 -
Flags: review?(wmccloskey)
Attachment #500115 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 24•14 years ago
|
||
Diagnotic 2 is in:
http://hg.mozilla.org/mozilla-central//rev/c35a4e6ea3ca
Comment 25•14 years ago
|
||
(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?
Assignee | ||
Comment 26•14 years ago
|
||
(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.
Comment 27•14 years ago
|
||
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.
Assignee | ||
Comment 28•14 years ago
|
||
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.
Assignee | ||
Comment 29•14 years ago
|
||
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
Reporter | ||
Comment 30•14 years ago
|
||
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)
Comment 31•14 years ago
|
||
It is #7 top crasher on Mac OS X in 4.0b8 for the last week.
Assignee | ||
Updated•14 years ago
|
Depends on: CVE-2011-0057
Updated•14 years ago
|
Group: core-security
Comment 32•14 years ago
|
||
hiding until we are sure this is unrelated to bug 626631 or have a fix there.
Updated•14 years ago
|
Whiteboard: [sg:critical?]
Reporter | ||
Comment 33•14 years ago
|
||
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.
Comment 34•14 years ago
|
||
bent has a setup that reliably triggers this crash. We should consider blocking on this and fixing it. What is the volume here?
Assignee | ||
Comment 35•14 years ago
|
||
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?
Comment 36•14 years ago
|
||
(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.
Comment 37•14 years ago
|
||
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.
Updated•14 years ago
|
Keywords: crash,
testcase-wanted
Comment 38•14 years ago
|
||
any status?
Assignee | ||
Comment 39•14 years ago
|
||
Updated•14 years ago
|
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)
Updated•14 years ago
|
Assignee | ||
Updated•14 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?][work ongoing in bug 637304]
Assignee | ||
Updated•14 years ago
|
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]
Updated•14 years ago
|
Crash Signature: [@ js::PropertyTable::search(int, bool) ]
[@ js::PropertyTable::search ]
Comment 40•13 years ago
|
||
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
Comment 41•13 years ago
|
||
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
Comment 42•13 years ago
|
||
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"
Comment 43•13 years ago
|
||
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)
Updated•13 years ago
|
Keywords: sec-moderate
Comment 44•13 years ago
|
||
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.
Updated•13 years ago
|
Blocks: 646745
Depends on: 569422, CVE-2011-0057
Updated•12 years ago
|
Summary: topcrash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ] → Crash in [@ js::PropertyTable::search(int, bool) ][@ js::PropertyTable::search ]
Comment 45•11 years ago
|
||
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: 11 years ago
Resolution: --- → WORKSFORME
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Keywords: testcase-wanted
Updated•7 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•