Closed Bug 602223 Opened 15 years ago Closed 15 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: 15 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: 15 years ago → 15 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: