Closed Bug 311950 Opened 19 years ago Closed 19 years ago

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

Categories

(Core :: JavaScript Engine, defect)

1.8 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: Peter6, Assigned: brendan)

References

()

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: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8rc1?
Keywords: crash, regressionfixed1.8
Flags: testcase-
You need to log in before you can comment on or make changes to this bug.