Closed Bug 311950 Opened 20 years ago Closed 20 years ago

crash at http://www.hansrossel.com/reisgids/turkijePR.html [@ js_LookupPropertyWithFlags ]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: Peter6, Assigned: brendan)

References

(
URL
)

Details

(Keywords: fixed1.8)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051008 Firefox/1.4.1 ID:2005100805 / vanilla profile Open url and crash this is NO dupe of Bug 276979 works in 20051004 1222pdt build fails in 20051004 1350pdt build regressionwindow : (bonsai down, will try later) TB10464972Y Incident ID: 10464972 Stack Signature js_LookupPropertyWithFlags e0c06551 Product ID Firefox15 Build ID 2005100805 Trigger Time 2005-10-10 04:42:13.0 Platform Win32 Operating System Windows NT 5.0 build 2195 Module js3250.dll + (0002d4be) URL visited http://www.hansrossel.com/reisgids/turkijePR.html User Comments crash while opening this page Since Last Crash 4391 sec Total Uptime 4391 sec Trigger Reason Access violation Source File, Line No. c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2592 Stack Trace js_LookupPropertyWithFlags [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2592] js_LookupProperty [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2519] js_GetProperty [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2804] nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 243] nsXPCWrappedJSClass::DelegatedQueryInterface [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 589] nsXPCWrappedJS::QueryInterface [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 97] nsEventListenerManager::HandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1779] nsXULDocument::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1242] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2135] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsXULElement::HandleDOMEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2132] nsEventStateManager::DispatchMouseEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2627] nsEventStateManager::NotifyMouseOut [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2696] nsEventStateManager::NotifyMouseOver [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2746] nsEventStateManager::GenerateMouseEnterExit [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2785] nsEventStateManager::PreHandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 522] PresShell::HandleEventInternal [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6361] PresShell::HandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6203] nsViewManager::HandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2559] nsViewManager::DispatchEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2246] HandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line 174] nsWindow::DispatchEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1252] nsWindow::DispatchMouseEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 5991] ChildWindow::DispatchMouseEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6242] nsWindow::WindowProc [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1434] USER32.dll + 0x3158f (0x77e4158f) USER32.dll + 0x31dc9 (0x77e41dc9) USER32.dll + 0x31e7e (0x77e41e7e) nsAppStartup::Run [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 151] main [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp, line 61] KERNEL32.dll + 0x28989 (0x79628989)
That seems very unlikely, whereas the fix for bug 311071 (just 6 mins outside your regression window) or bug 311090 seems much more probably. Note that 6 mins is well within the range of cvs-mirror lag or machine clock skew...
Flags: blocking1.8rc1?
Severity: normal → critical
Keywords: talkbackid
I don't think E4X changes could cause this. How about the nsDOMClassInfo.cpp changes? We should get this bug well-assigned (not that mrbkap needs any more criticals just now -- but this bug is not critical ;-). Could cx be bad? What line is implicated in js_LookupPropertyWithFlags, can someone show the source from the right cvs pull date? /be
Assignee: general → general
Severity: critical → normal
Component: JavaScript Engine → DOM: Level 0
QA Contact: general → ian
This is still critical severity. > I don't think E4X changes could cause this. Think again. ;) In a debug branch build: Assertion failure: tt == TOK_XMLCDATA || tt == TOK_XMLCOMMENT || tt == TOK_XMLPI, at ../../../mozilla/js/src/jsparse.c:3499 Program received signal SIGABRT, Aborted. #3 0xb7fd0adf in JS_Assert ( s=0xb7ff47a4 "tt == TOK_XMLCDATA || tt == TOK_XMLCOMMENT || tt == TOK_XMLPI", file=0xb7ff4108 "../../../mozilla/js/src/jsparse.c", ln=3499) at ../../../mozilla/js/src/jsutil.c:63 #4 0xb7faf762 in XMLElementContent (cx=0x87c3d68, ts=0x89401b0, pn=0x89404b0, tc=0xbfffe560) at ../../../mozilla/js/src/jsparse.c:3498 #5 0xb7fafb90 in XMLElementOrList (cx=0x87c3d68, ts=0x89401b0, tc=0xbfffe560, allowList=1) at ../../../mozilla/js/src/jsparse.c:3590 #6 0xb7fb0b1b in PrimaryExpr (cx=0x87c3d68, ts=0x89401b0, tc=0xbfffe560) at ../../../mozilla/js/src/jsparse.c:3993 #7 0xb7fae4ab in MemberExpr (cx=0x87c3d68, ts=0x89401b0, tc=0xbfffe560, allowCallSyntax=1) at ../../../mozilla/js/src/jsparse.c:2891 ... #26 0xb7f3e525 in JS_CompileUCScriptForPrincipals (cx=0x87c3d68, obj=0x8b316d8, principals=0x8a38b94, chars=0x899f0c8, length=270, filename=0x87ec958 "http://www.hansrossel.com/javascript/dontgetframed.js", lineno=1) at ../../../mozilla/js/src/jsapi.c:3681 That script looks like this: <script language="javascript"> <!-- kleef in head om niet geframed te worden --> <!-- if (self.location.href != top.window.location.href) { top.window.location.href = self.location.href }; if (top.frames.length!=0) top.location=self.document.location; //--> </script> (yes, in an external script file; gotta love these folks). For what it's worth, in frame 4 when we assert we have: (gdb) p tt $3 = TOK_IF (gdb) p ts->lineno $9 = 4 Oh, and backing out the patch for bug 311071 fixes this crash.
Assignee: general → general
Blocks: 311071
Severity: normal → critical
Component: DOM: Level 0 → JavaScript Engine
OS: Windows 2000 → All
QA Contact: ian → general
Hardware: PC → All
Assignee: general → brendan
Boris, this is with the fix for bug 311157 in your tree, right?
No, that was without that patch -- I pulled my 1.8 tree last night. With that patch, I don't see a crash on the site in this bug. So sounds like this was fixed by that patch... If that's a likely possibility, please resolve accordingly.
Depends on: 311157
Yes, fixed indeed, resolving
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking1.8rc1?
Keywords: crash, regression → fixed1.8
Flags: testcase-
You need to log in before you can comment on or make changes to this bug.