Closed Bug 602223 Opened 14 years ago Closed 14 years ago

crash when typing javascript:this in the Web Console [@ js::PropertyTable::search(int, bool) ]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: scoobidiver, Assigned: mrbkap)

References

Details

(4 keywords, Whiteboard: see comment 28 for javascript:this bug)

Crash Data

Attachments

(1 file)

Fix
2.37 KB, patch
gal
: review+
Details | Diff | Splinter Review 
Build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

It is a new crash signature that exist in trunk builds.
It is #38 top crasher in 4.0b7pre build for the last week.

Signature	js::PropertyTable::search(int, bool)
UUID	3edaf174-b804-4eff-9651-6688c2101006
Time 	2010-10-06 06:58:42.715751
Uptime	0
Last Crash	93 seconds before submission
Install Age	320131 seconds (3.7 days) since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20101002041357
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 15 model 6 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x6c

Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:363
1 	mozjs.dll 	js_LookupPropertyWithFlags 	js/src/jsobj.cpp:4620
2 	mozjs.dll 	js_SetPropertyHelper 	js/src/jsobj.cpp:5171
3 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4324
4 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:638
5 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:746
6 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:776
7 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4836
8 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
9 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:571
10 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
11 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
12 	xul.dll 	nsComponentManagerImpl::CreateInstance 	xpcom/components/nsComponentManager.cpp:1216
13 	xul.dll 	nsComponentManagerImpl::GetService 	xpcom/components/nsComponentManager.cpp:1468
14 	xul.dll 	nsJSCID::GetService 	js/src/xpconnect/src/xpcjsid.cpp:845
15 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
16 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1752
17 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4625
18 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:638
19 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:746
20 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:776
21 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4836
22 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
23 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:571
24 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
25 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
26 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=js%3A%3APropertyTable%3A%3Asearch%28int%2C%20bool%29&version=Firefox%3A4.0b7pre
Summary: crash → crash [@ js::PropertyTable::search(int, bool) ]
Confirmed, just happened to me when i tried to sync.
Got this one:

http://crash-stats.mozilla.com/report/index/bp-2eb8299b-9f7c-46c6-8d1f-e69362101019

Related? Can reproduce it always. Offending line in my crash report seems to be "hash1 = HASH1(hash0, hashShift);"
Just got this myself: bp-c13be4c4-b84e-4a2b-9f7d-494b72101101

STR:

1) Type javascript:this in the Web Console on the about:home page.
2) Click on the resulting [object Window]
3) BOOM!
blocking2.0: --- → ?
Currently top crasher number 43 for beta8pre.
Keywords: topcrash
Keywords: reproducible
Comment 3 suggests this-wrapping or something related to wrappers. Thoughts?

/be
Attached patch Fix — — Splinter Review 
obj->getParent() can return null for global objects so we should use obj->getGlobal() which will always return non-null.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #487473 - Flags: review?(gal)
Blocks: 608862
Attachment #487473 - Flags: review?(gal) → review+
Trivial and safe fix, we should get this in for beta7.
blocking2.0: ? → beta7+
http://hg.mozilla.org/mozilla-central/rev/addeb77512a8
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
No crash here using the STR from comment #3 on today's nightly m-c build win32 running on Win7 x64
(In reply to comment #10)
> It is not fixed as it happens in the latest build.
> 

are you sure, Scoobidiver?  because I'm not getting any crashes so far with the latest trunk build of FF 4.0b8pre (20101104) on my WinXP x86 computer.

and Jim before me is not getting any crashes either with the latest mozilla-central FF4b8pre nightly build.

gonna try out the latest t-m (tracemonkey) build to also make sure shortly.
so far, no crashes with the latest t-m FF4.0b8pre nightly build of Nov. 4 that I've just tested.  I just can't get the darn thing to blow up, no matter what.

I'm still scratching my head as to why you are still experiencing crashes, Scoobidiver.  do the crashes still happen randomly on your computer even with the latest nightlies?
show us here (aka. steps to reproduce) on how the crash occurs on your machine with the recent b8pre nightlies.
on ubuntu, using comment3 STR
crash with latest tm nightly:
http://crash-stats.mozilla.com/report/index/5f930ce8-400e-4a98-867d-ac65d2101104
no crash in latest m-c nightly
> I'm still scratching my head as to why you are still experiencing crashes,
> Scoobidiver.  do the crashes still happen randomly on your computer even with
> the latest nightlies?
It does not happen on my computer. The reopening is only based on crash stats.
Go to Graph tab of crash reports I gave in comment 10.
For the moment, there has been no crash in 4.0b8pre/20101104 build, but this build was released 2 hours ago.
Why not finally create the long overdue b7 builds, test the bug on them, and if the bug is really still there (as does not seem to be the case based on Comment 14) and it is required, do a respin?
(In reply to comment #14)
> on ubuntu, using comment3 STR
> crash with latest tm nightly:
> http://crash-stats.mozilla.com/report/index/5f930ce8-400e-4a98-867d-ac65d2101104
> no crash in latest m-c nightly

no crash in latest m-c linux hourly build (1288864761), either
Are crash-reports a valid indicator that something is not fixed ?

Not knowing the end-users config/addons etc when he crashed is a huge unknown, and may not, in my mind, be the same exact crasher as this bug.
ok.  can anyone with a Mac OS X reproduce the crash with the latest m-c and t-m nightlies?
RE: Comment 16, sounds like a good idea. That will accomplish two tasks, one to have a b7 build and second to test this bug!
(In reply to comment #18)
> Are crash-reports a valid indicator that something is not fixed ?
> 
> Not knowing the end-users config/addons etc when he crashed is a huge unknown,
> and may not, in my mind, be the same exact crasher as this bug.

let's see if Scoobidiver can answer your question, Jim.  after all, he was the one who reported this bug about a month ago.
tried to reproduce this on latest nightly on xp and didn't get a crash on about:home but with the link from comment 14 i got bug 609626...
(In reply to comment #20)
> RE: Comment 16, sounds like a good idea. That will accomplish two tasks, one to
> have a b7 build and second to test this bug!

Task #3: it's not very unlikely that other issues will show up that will force
respins, once the b7 builds are there. But there is no way of finding out about
those as long as there are no b7 builds.

Everything should be much easier if there is a "real thing" to test on.
The nightlies are as suitable for test as beta7, for purposes of checking this bug.  Please keep comments in this bug focused on the topic of the bug; you can post to mozilla.dev.planning if you want to discuss scheduling, or attend the development/product calls.
(In reply to comment #22)
> tried to reproduce this on latest nightly on xp and didn't get a crash on
> about:home but with the link from comment 14 i got bug 609626...

With the javascript:this Web Console instructions I get 609626 also. Windows Server 2003 R2 Standard Edition on VMWare, happens with latest nightly.
> Are crash-reports a valid indicator that something is not fixed ?
One crash signature can be caused by several reasons.
For this particular case, crash reason is EXCEPTION_ACCESS_VIOLATION_READ. But if you analyze a lot of stack traces, the first three threads are various, so it can be considered as a meta bug.
Feel free to open a new bug for each different stack trace if you have a fix for each one.

Here are some examples of stack traces:
0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:316
1 	mozjs.dll 	JSObject::nativeLookup 	js/src/jsscope.h:645
2 	mozjs.dll 	js_DefineNativeProperty 	js/src/jsobj.cpp:4420

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:316
1 	mozjs.dll 	JSObject::nativeLookup 	js/src/jsscope.h:645
2 	mozjs.dll 	js_GetPropertyHelper 	js/src/jsobj.cpp:5064

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:325
1 	mozjs.dll 	js_AtomizeString 	js/src/jsatom.cpp:478
2 	mozjs.dll 	js_DefineProperty 	js/src/jsobj.cpp:4294

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:312
1 	mozjs.dll 	js_LookupPropertyWithFlags 	js/src/jsobj.cpp:4650
2 	mozjs.dll 	js_FindPropertyHelper 	js/src/jsobj.cpp:4676

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:312
1 	mozjs.dll 	js_LookupPropertyWithFlags 	js/src/jsobj.cpp:4650
2 	mozjs.dll 	js_FindClassObject 	js/src/jsobj.cpp:3988

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:325
1 	mozjs.dll 	js_LookupProperty 	js/src/jsobj.cpp:4640
2 	mozjs.dll 	js_HasOwnProperty 	js/src/jsobj.cpp:1416

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:366
1 	mozjs.dll 	js_LookupProperty 	js/src/jsobj.cpp:4640
2 	mozjs.dll 	JSObject::lookupProperty 	js/src/jsobj.h:1062

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:312
1 	mozjs.dll 	js_GetProperty 	js/src/jsobj.cpp:5071
2 	mozjs.dll 	js::mjit::ic::GetProp 	js/src/methodjit/PolyIC.cpp:1656

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:366
1 	mozjs.dll 	js::PropertyTable::change 	js/src/jsscope.cpp:427
2 	mozjs.dll 	JSObject::addPropertyInternal 	js/src/jsscope.cpp:763

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:312
1 	mozjs.dll 	js::proxy_Call 	js/src/jsproxy.cpp:1027
2 	mozjs.dll 	JSCompartment::wrap 	js/src/jscompartment.cpp:120

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:312
1 	mozjs.dll 	JSContext::realloc 	js/src/jscntxt.h:2262
2 	mozjs.dll 	JSObject::allocSlot 	js/src/jsobj.cpp:4098
@Jim Jeffery and others: I got the recent nightlies to crash & burn.
my earlier comments were not clear enough to determine the whole picture so you can disregard them.

You're supposed to type "javascript:this" in the Web Console window, NOT the Address Bar.

CLEAR Steps to Reproduce:
1.  From the Menu bar, click on Tools and select Web Console
2.  From the Web Console prompt (NOT the Address bar) ">" type in javascript:this
3.  Click on the underlined [object window] link.

Actual Result: Crash
Expected Result: No crash

If you type javascript:this in the Address bar only, you won't get the crash.
The javascript:this bug has been moved to bug 608862.
Whiteboard: see comment 28 for javascript:this bug
Drat!  I forgot to mention that you have to go to a web site before opening the Web Console window.  The Web Console window will NOT show up on a blank browser tab.

Even CLEARER steps to reproduce:
1.  Type in any web site in the Address bar (ex. www.google.com, www.yahoo.com, etc.) and hit Enter to go to that site
2.  Click Tools and choose Web Console
3.  On the Web Console prompt only, type in javascript:this
3.  Click the [object window] link

the actual result should be a crash.

I was able to reproduce this in both the recent m-c and t-m FF4.0b8pre builds on my XP computer.
this is bug 609626 ...
Moving off to beta8 as we think that one of if the issues is solved, and bug 609626 is blocking beta8
blocking2.0: beta7+ → beta8+
I cannot reproduce this on: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101103 Firefox/4.0b8pre
Can we please file a new bug on the remaining crash? The patch in this bug definitely *did* fix *a* crash at PropertyTable::search and bugzilla + multiple patches make for long, sad bugs.
If you are coming here from crash stats, please file other bugs on remaining issues. The patch in this bug fixed one instance of a crash with this signature, but there may be more that map back to js::PropertyTable::search(int, bool) as well.

Closing this out as a b7 blocker, because that's what it was when we took the fix.
Status: REOPENED → RESOLVED
blocking2.0: beta8+ → beta7+
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Summary: crash [@ js::PropertyTable::search(int, bool) ] → crash when typing javascript:this in the Web Console [@ js::PropertyTable::search(int, bool) ]
> Now I have a new crash:
> http://crash-stats.mozilla.com/report/index/bp-14637a4f-e6d1-440d-81b9-2f3fc2101108
Yakove, did you get this crash with the STR in comment 3? If not, please file a new bug.
No, there are no crash with the STR in comment 3
Group: core-security
hiding until we are sure this is unrelated to bug 626631 or have a fix there.
Crash Signature: [@ js::PropertyTable::search(int, bool) ]
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: