Closed Bug 317283 Opened 19 years ago Closed 15 years ago

[1.8 branch] Crash [@js_LookupPropertyWithFlags] (sometimes view source?)

Categories

(Core :: JavaScript Engine, defect, P2)

Product:
Core
Component:
JavaScript Engine
Version:
1.8 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.8.1beta2

People

(Reporter: tonymec, Unassigned)

References

Details

(4 keywords, Whiteboard: topcrash #14, DUPEME; wfm 1.9.0)

Crash Data

Attachments

(7 files)

testcase from François
73.89 KB, text/html
Details
call stack with arguments and locals
167.10 KB, image/jpeg
Details
partly minimized testcase
29.55 KB, text/html
Details
partly minimized testcase2
17.10 KB, text/html
Details
partly minimized testcase3
7.09 KB, text/html
Details
patch?
1.70 KB, patch
brendan
: review-
Details | Diff | Splinter Review
backtrace from mingw debug build
7.64 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051120 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051120 Firefox/1.5

See Talkback event TB12076433X

Reproducible: Didn't try

Steps to Reproduce:

Actual Results:  
crash

Expected Results:  
no crash

Html Validator 0.7.6 splits the View Source window into 3 panes.
Version: unspecified → 1.5 Branch
From talkback ID:
URL visited	file://localhost/C:/Documents%20and%20Settings/Tony/Mijn%20documenten/pub/chroniq/noms/noms_b.htm#B
User Comments	Clicking "View source" N.B. An earlier version of the same file exists online at http://users.skynet.be/antoine.mechelynck/chroniq/noms/noms_b.htm

js_LookupPropertyWithFlags  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2653]
js_LookupProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2580]
js_GetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2865]
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 591]
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]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2153]
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::HandleChromeEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2833]
nsGlobalWindow::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1533]
nsDocument::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 3999]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2123]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2117]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2117]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2117]
nsGenericHTMLElement::HandleDOMEventForAnchors  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 1491]
nsHTMLAnchorElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp, line 295]
nsEventStateManager::DispatchMouseEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2628]
nsEventStateManager::NotifyMouseOver  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2754]
nsEventStateManager::GenerateMouseEnterExit  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2786]
nsEventStateManager::PreHandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 523]
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 5982]
ChildWindow::DispatchMouseEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6233]
nsWindow::WindowProc  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1434]
USER32.dll + 0x8734 (0x77d18734)
USER32.dll + 0x8816 (0x77d18816)
USER32.dll + 0x89cd (0x77d189cd)
USER32.dll + 0x8a10 (0x77d18a10)
nsAppShell::Run  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsAppShell.cpp, line 159]
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 + 0x16d4f (0x7c816d4f)

So you mean this only happened when you have the HTML Validator extension installed?
Keywords: crash
(In reply to comment #1)
[...]
> So you mean this only happened when you have the HTML Validator extension
> installed?

No, I mean that HTML Validator was installed at the time of the crash, and that that might have an impact on what exactly "View Source" did, since that extension (among other things) installs its 3-pane GUI in the "View Source" window. I have not tried uninstalling that extension, which I find very useful.
Related to bug 314260?
*** Bug 314260 has been marked as a duplicate of this bug. ***
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: 1.5 Branch → 1.8 Branch
Brendan asked me to find a bug about a crash [@ js_LookupPropertyWithFlags] and CC bz on it.  This is the #29 crash signature for Firefox 1.5 RC3 with 0.64% of all crashes (147 of 22930).  See http://talkback-public.mozilla.org/reports/firefox/FF15rc3/FF15rc3-topcrashers.html.

All of the Talkback reports I looked at had nsXULElement::HandleDOMEvent on the stack, and some XPCWrappedJSClass function above it.

Talkback IDs:

  through nsXPCWrappedJSClass::DelegatedQueryInterface:
    12356210, 12352320, 12331758, 12298940

  through nsXPCWrappedJSClass::CallMethod:
    12324412
ok, the test case in bug 326411 give me a crash stack very similar to this bug (TB17420666).

testcase crashing FF: https://bugzilla.mozilla.org/attachment.cgi?id=211943
I was able to reproduce this on FFx 1.5.0.4rc2 and Bon Echo from 2006-05-09 using the testcase given in comment #6

This is showing up more regularly in topcrash reports of late.

list of incedents: http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=js_LookupPropertyWithFlags%0D%0A&vendor=MozillaOrg&product=Firefox2&platform=All&buildid=2006&sdate=&stime=&edate=&etime=&sortby=bbid&rlimit=500
Flags: blocking1.8.1?
Flags: blocking1.8.0.4?
Keywords: topcrash+
> This is showing up more regularly in topcrash reports of late.

For Firefox 2, jumped to #8 based on 6 crashes out of 250 (~2.4%)--at least it appears to have jumped, but hard to tell given the low numbers. The old frequency would have been 1 or 2 crashes, but those extra 4 could have been someone trying the testcase in the bug.

In Firefox 1.5.0.3 it's still a #26 crash with 0.57% frequency (366 out of 63723). We haven't done anything to make this worse, I can't see how it would block 1.5.0.4 anything. (if a patch shows up it could go into 1.5.0.5 or later, but get the patch first.)

Might as well confirm the bug, though. It's obviously a real crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crash on View Source [@js_LookupPropertyWithFlags] → Crash [@js_LookupPropertyWithFlags] (sometimes view source?)
Flags: blocking1.8.0.4? → blocking1.8.0.4-
comment #6 test case now crash [@ nsComboboxControlFrame::CreateAnonymousContent] and no more at [@js_LookupPropertyWithFlags].
this should either be a dom, xul, or xpconnect bug. so i'm randomly bouncing it for kicks.
Assignee: general → general
Component: JavaScript Engine → DOM
QA Contact: general → ian
François Gagné, the crash you mentioned is bug 318254. Although the testcase in comment 6 previously yielded the crash in this bug, it's not anymore (at least for me).
So is there a semi-reliable way to reproduce?  Maybe with TOO_MUCH_GC?
Flags: blocking1.8.1? → blocking1.8.1+
No method to reproduce, so not going to block FF 2 beta1 for this.  Though it would be nice to get a fix for FF2!
Flags: blocking1.8.1+ → blocking1.8.1-
Whiteboard: [ff2b2]
Flags: blocking1.8.1- → blocking1.8.1+
Whiteboard: [ff2b2]
Target Milestone: --- → mozilla1.8.1beta2
Flags: blocking1.8.1+ → blocking1.8.1-
Has anyone investigated whether there's a reliable way to reproduce this bug, perhaps with the HTML Validator extension, and perhaps with WAY_TOO_MUCH_GC ?
Perhaps a new way to reproduce, from TB24753078, TB24752946 .

Stack Signature	 js_LookupPropertyWithFlags a33ed43c
URL visited	http://www.samsfactory.be/ateliers
User Comments	edit css from webdeveloper while a quicktime was playing

I tryed the user comment and I did crash (but my talkbalk are junk so I'm not sure I do crash on js_LookupPropertyWithFlags)

Step I did :
1) Open http://www.samsfactory.be/ateliers
2) Click on a movie and wait for it to play
3) Use "Edit CSS" from the web developer extension
4) Edit the color of some link 'a'
5) Apply the change
6) Repeat step 4) and 5)
7) Do a "Reset all" (the icon similar to reload)

CRASH!

Could someone test this?
Whiteboard: See comment 15
Follow up on comment 15, I crash at @GetFrameFromLine (see TB25365069G, TB25362702E) not on @js_LookupPropertyWithFlags.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061101 BonEcho/2.0 ID:2006110104



Stack: 

GetFrameFromLine  [mozilla/layout/generic/nsBlockFrame.cpp, line 6877]
nsBlockFrame::GetFrameForPointUsing  [mozilla/layout/generic/nsBlockFrame.cpp, line 6952]
nsBlockFrame::GetFrameForPoint  [mozilla/layout/generic/nsBlockFrame.cpp, line 6988]
PresShell::HandleEvent  [mozilla/layout/base/nsPresShell.cpp, line 6205]
nsViewManager::HandleEvent  [mozilla/view/src/nsViewManager.cpp, line 2514]
nsViewManager::DispatchEvent  [mozilla/view/src/nsViewManager.cpp, line 2246]
HandleEvent  [mozilla/view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1377]
nsWindow::DispatchFocus  [mozilla/widget/src/windows/nsWindow.cpp, line 6522]
nsWindow::ProcessMessage  [mozilla/widget/src/windows/nsWindow.cpp, line 5090]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1565]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0xb4c0 (0x77d4b4c0)
USER32.dll + 0xb50c (0x77d4b50c)
ntdll.dll + 0xeae3 (0x7c90eae3)
nsView::~nsView  [mozilla/view/src/nsView.cpp, line 267]
nsSplittableFrame::Destroy  [mozilla/layout/generic/nsSplittableFrame.cpp, line 71]
nsObjectFrame::Destroy  [mozilla/layout/generic/nsObjectFrame.cpp, line 775]
nsFrameList::DestroyFrames  [mozilla/layout/generic/nsFrameList.cpp, line 138]
nsLineBox::DeleteLineList  [mozilla/layout/generic/nsLineBox.cpp, line 325]
nsLineBox::DeleteLineList  [mozilla/layout/generic/nsLineBox.cpp, line 325]
nsLineBox::DeleteLineList  [mozilla/layout/generic/nsLineBox.cpp, line 325]
nsLineBox::DeleteLineList  [mozilla/layout/generic/nsLineBox.cpp, line 325]
nsFrameList::DestroyFrame  [mozilla/layout/generic/nsFrameList.cpp, line 234]
nsCSSFrameConstructor::ContentRemoved  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10048]
nsCSSFrameConstructor::RecreateFramesForContent  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 12004]
nsCSSFrameConstructor::ProcessRestyledFrames  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10437]
nsIPresShell::ReconstructStyleDataInternal  [mozilla/layout/base/nsPresShell.cpp, line 5608]
PresShell::EndUpdate  [mozilla/layout/base/nsPresShell.cpp, line 3581]
nsCSSStyleSheet::SetDisabled  [mozilla/layout/style/nsCSSStyleSheet.cpp, line 2060]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_GetterSetter  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1479]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1377]
js_InternalInvoke  [mozilla/js/src/jsinterp.c, line 1471]
JS_CallFunctionValue  [mozilla/js/src/jsapi.c, line 4419]
XPC_NW_GetOrSetProperty  [mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 588]
XPC_NW_SetProperty  [mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 613]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1396]
js_InternalInvoke  [mozilla/js/src/jsinterp.c, line 1471]
JS_CallFunctionValue  [mozilla/js/src/jsapi.c, line 4419]
nsJSContext::CallEventHandler  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1493]
nsJSEventListener::HandleEvent  [mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1657]
DocumentViewerImpl::LoadComplete  [mozilla/layout/base/nsDocumentViewer.cpp, line 1013]
nsDocShell::EndPageLoad  [mozilla/docshell/base/nsDocShell.cpp, line 4795]
nsWebShell::EndPageLoad  [mozilla/docshell/base/nsWebShell.cpp, line 665]
nsDocShell::OnStateChange  [mozilla/docshell/base/nsDocShell.cpp, line 4710]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
imgRequestProxy::RemoveFromLoadGroup  [mozilla/modules/libpr0n/src/imgRequestProxy.cpp, line 182]
imgRequestProxy::OnStopRequest  [mozilla/modules/libpr0n/src/imgRequestProxy.cpp, line 528]
imgRequest::OnStopRequest  [mozilla/modules/libpr0n/src/imgRequest.cpp, line 767]
ProxyListener::OnStopRequest  [mozilla/modules/libpr0n/src/imgLoader.cpp, line 880]
A crash with the same stack trace happens for me now with Thunderbird. The window was opened in the background and I moved with the mouse over the window title to click on the minimize button. Then Thunderbird crashed:

Talkback id: TB28278990Y

Stack Signature	 js_LookupPropertyWithFlags 9cfc61fe
Product ID	Thunderbird2
Build ID	2007011004
Trigger Time	2007-01-12 00:12:11.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (00031a45)
URL visited	
User Comments	Moving mouse over window title to minimize the application
Since Last Crash	2096 sec
Total Uptime	28182 sec
Trigger Reason	Access violation
Source File, Line No.	e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/js/src/jsobj.c, line 3187
Stack Trace 	
js_LookupPropertyWithFlags  [mozilla/js/src/jsobj.c, line 3187]
js_LookupProperty  [mozilla/js/src/jsobj.c, line 3114]
js_GetProperty  [mozilla/js/src/jsobj.c, line 3491]
nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 243]
nsXPCWrappedJSClass::DelegatedQueryInterface  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 595]
nsXPCWrappedJS::QueryInterface  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 106]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1752]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2230]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2209]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2209]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2209]
nsEventStateManager::DispatchMouseEvent  [mozilla/content/events/src/nsEventStateManager.cpp, line 2797]
nsEventStateManager::NotifyMouseOver  [mozilla/content/events/src/nsEventStateManager.cpp, line 2922]
nsEventStateManager::GenerateMouseEnterExit  [mozilla/content/events/src/nsEventStateManager.cpp, line 2954]
nsEventStateManager::PreHandleEvent  [mozilla/content/events/src/nsEventStateManager.cpp, line 567]
PresShell::HandleEventInternal  [mozilla/layout/base/nsPresShell.cpp, line 6419]
PresShell::HandleEvent  [mozilla/layout/base/nsPresShell.cpp, line 6261]
nsViewManager::HandleEvent  [mozilla/view/src/nsViewManager.cpp, line 2559]
nsViewManager::DispatchEvent  [mozilla/view/src/nsViewManager.cpp, line 2246]
HandleEvent  [mozilla/view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1389]
nsWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6435]
ChildWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6682]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1577]
USER32.dll + 0x8734 (0x77d18734)
USER32.dll + 0x8816 (0x77d18816)
USER32.dll + 0x89cd (0x77d189cd)
USER32.dll + 0x8a10 (0x77d18a10)
nsAppShell::Run  [mozilla/widget/src/windows/nsAppShell.cpp, line 159]
nsAppStartup::Run  [mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 152]
main  [mozilla/mail/app/nsMailApp.cpp, line 62]
kernel32.dll + 0x16fd7 (0x7c816fd7)
Assignee: general → jst
Good news,

Here an URL telling how to crash with js_LookupPropertyWithFlags:
http://jsx.cc/firefox/diff.html

Here my talkback TB34424073M

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6pre) Gecko/20070727 BonEcho/2.0.0.6pre ID:2007072704
Thanks for that testcase, François!
I get a regression range on the 1.8.1 branch between 2006-09-12 and 2006-09-13:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-12+03&maxdate=2006-09-13+06&cvsroot=%2Fcvsroot
On trunk I've tested with a 2006-09-11 build which doesn't crash and a 2006-09-13 build which does crash, so same regression range.
It seems this doesn't crash on the 1.8.0.x tree, I've tried it with the latest 1.8.0.x build.

On trunk it seems to be fixed somehow in the latest trunk builds.
I crash with a 2007-03-07 trunk build, but I don't crash anymore with a 2007-03-08 trunk build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-07+04&maxdate=2007-03-08+09&cvsroot=%2Fcvsroot
This is the testcase from François. I've added an automatic reload function in it, for easier crashing.
I get a different stacktrace with it, though, not sure if that matters. Talkback ID: TB34439062E
The branch regression range corresponds to a whole bunch of JS stuff landing on the branch.  The trunk "it got fixed" range corresponds to several JS fixes too.  I'm willing to bet this is a JS engine bug...
Assignee: jst → general
Component: DOM → JavaScript Engine
Flags: blocking1.8.1.7-
QA Contact: ian → general
Boris, I think you wanted to blocking1.8.1.7+ it, right?
Let me know if you want to have a smaller testcase (I could try).
Flags: blocking1.8.1.7- → blocking1.8.1.7?
I meant to "blocking1.8.1.7?"....

No idea about testcase.  Brendan or Igor would be the ones to ask.
Brendan, Igor, Crowder: would it be possible to track down what caused this crash to increase into a topcrash, and what fixed it on the trunk? regression and fix ranges are in comment 19
Flags: blocking1.8.1.7? → blocking1.8.1.7+
Keywords: regression
Assignee: general → igor
Why is this QAwanted? We have a reduced test case for this.
It was added with comment 14 and can be removed now.
Keywords: qawanted
It might be useful to get a smaller testcase (it isn't exactly reduced).
I asked that in comment 22, but I didn't get a reply from Brendan or Igor, so I'm not going to try that just yet, since it's a lot of work.
I tried to run the testcase once again and I'm getting a total different stack trace (TB35460264G):

msvcrt.dll + 0x372e3 (0x77c172e3)
SprintPut  [mozilla/js/src/jsopcode.c, line 406]
js_DecompileCode  [mozilla/js/src/jsopcode.c, line 4226]
js_DecompileFunction  [mozilla/js/src/jsopcode.c, line 4424]
JS_DecompileFunction  [mozilla/js/src/jsapi.c, line 4154]
fun_toString  [mozilla/js/src/jsfun.c, line 1543]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3946]
js_Execute  [mozilla/js/src/jsinterp.c, line 1634]
JS_EvaluateUCScriptForPrincipals  [mozilla/js/src/jsapi.c, line 4296]
nsJSContext::EvaluateString  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1100]
nsScriptLoader::EvaluateScript  [mozilla/content/base/src/nsScriptLoader.cpp, line 813]
nsScriptLoader::ProcessRequest  [mozilla/content/base/src/nsScriptLoader.cpp, line 711]
nsScriptLoader::DoProcessScriptElement  [mozilla/content/base/src/nsScriptLoader.cpp, line 644]
nsScriptLoader::ProcessScriptElement  [mozilla/content/base/src/nsScriptLoader.cpp, line 396]
nsHTMLScriptElement::MaybeProcessScript  [mozilla/content/html/content/src/nsHTMLScriptElement.cpp, line 663]
nsHTMLScriptElement::BindToTree  [mozilla/content/html/content/src/nsHTMLScriptElement.cpp, line 456]
nsGenericElement::AppendChildTo  [mozilla/content/base/src/nsGenericElement.cpp, line 2876]
HTMLContentSink::ProcessSCRIPTTag  [mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 4174]
HTMLContentSink::AddLeaf  [mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 3040]
HTMLContentSink::AddHeadContent  [mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 2991]
CNavDTD::AddHeadLeaf  [mozilla/parser/htmlparser/src/CNavDTD.cpp, line 3609]
CNavDTD::HandleToken  [mozilla/parser/htmlparser/src/CNavDTD.cpp, line 955]
CNavDTD::BuildModel  [mozilla/parser/htmlparser/src/CNavDTD.cpp, line 458]
nsParser::BuildModel  [mozilla/parser/htmlparser/src/nsParser.cpp, line 2169]

Is this the same issue or a different one?
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.9+
Flags: blocking1.8.1.8+
Whiteboard: See comment 15 → topcrash #14
There are three stack traces in this bug report. Two of them are familiar to me as problems hit by Firebug.  They look completely different, but I think they may be the same problem. 

Based on tracing output from Firebug I am fairly confident that the stack from talkback 36785076 is caused by jsdIScript.functionSource. This stack ends with "detecting" but the preceding call is js_LookupProperty and two up is QI. Notice that the call stack at the top of this report has js_LookupProperty and two up is QI. Now the third call stack in this report, just above me here, is a seemingly completely different trace, but it has js_DecompileCode.  This latter trace is one that comes up often in Firebug 1.1. 

There is a small and two large mysteries here:
 small: why is the trace right above me here calling decompile
 large: why does jsdIScript.functionSource die on QI
 large: whats the bug here?

This is an important bug to fix for firebug because otherwise we cannot use jsdIScript.functionSource and we lose the ability to debug event handlers.  Venkman probably does not hit these cases because the scripts that crash Firebug are in event handlers that Venkman cannot see.

Also the code in question is a 724 line event handler from http://pagead2.googlesyndication.com/pagead/show_ads.js so it crashes Firebug a lot.
Ok so I know much of what I said makes no sense. But then neither do the stack traces. 

What I am pretty sure of is that 
  jsdIScript.functionSource crashes
  the stack has QI 
  QI calls Detecting
  Detecting looks at script bytecodes. 
The crash line for talkback 36786514
Detecting  [mozilla/js/src/jsobj.c, line 3117]
 for (endpc = script->code + script->length; pc < endpc; pc++) 

And jsdIScript.functionSource crashes in other cases.

I'm going to see what happens in FF3.
The image is a stack that looks like the one at the top of this bug report. Note cx=0 for first arg on top of stack.
The attached image from Max Stepanov on a test case from Firebug that resembles the first one in this report.  He notes the two top frames:
js_LookupPropertyWithFlags(cx=0, ....)
js_LookupProperty(cx=some hex value, ....)

And here is a code for js_LookupProperty. I'm wondering how cx value could become NULL there.
---
js_LookupProperty(JSContext *cx, JSObject *obj, jsid id, JSObject **objp, JSProperty **propp)
{
    return js_LookupPropertyWithFlags(cx, obj, id, 0, objp, propp);
}
---

(So far I have not found any of these functionSource-related crashes to happen on FF3.0a8; also mostly these crashes are do not reproduce the first time and resist reduction to small examples: they seems to be timing related).
> I'm wondering how cx value could become NULL there.

Something stomped on the stack?  That's the only thing I can think of.
Are optimizations turned on? That can be deceiving at times. I would really need to see the disassembly of the two functions to know for sure.
I can repetitive reproduce this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8pre) Gecko/20071016 BonEcho/2.0.0.8pre and Firebug 1.05 installed.

You only have to open following page. Firefox stops responding and crashes when clicking within the main window.

http://forums.lavag.org/LabVIEW-85-Buglist-f92.html

Talkback: TB37049613Q
I used the LabVIEW link on 2.0.0.8rc2 with Firebug 1.1.0b5 and it crashed.

I tried on 3.0a8 and no crash.

The LabVIEW link uses http://pagead2.googlesyndication.com/pagead/ads, as do many of the pages that crash with Firebug.
If this crashes branch but not trunk, it might be interesting to find the last trunk build that crashes and the first trunk build that does not and post that information here.  Please include the hour, as well as date, of those builds.
See comment 19 (it would be good is someone could recheck it, perhaps).
The 1.8.1 branch builds have timestamps of firefox.exe for 2006-09-12: 5:17 am
and for 2006-09-13: 5:34 am.
Hmm.  That trunk range only has cycle collection stuff and JS_GetString(Bytes|Chars) stuff that looks possibly relevant...
FYI, I tried to reproduce the crash on Mac OS X 10.4 but it didn't crash. All comments above talk about Windows. So it seems to be a Windows only crash.
From comment 19 and the testcase (attachment 274267 [details]), I can confirm martijn's 1.8.1 branch range:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/2006091203 BonEcho/2.0b2
- testcase WFM 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/2006091303 BonEcho/2.0b2
- testcase crashes

Checkins to module PhoenixTinderbox on branch MOZILLA_1_8_BRANCH between 2006-09-12 02:00 and 2006-09-13 04:00 : 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-12+02&maxdate=2006-09-13+04&cvsroot=%2Fcvsroot



On the trunk, thanks to Peter6 and his extensive hourly builds archive, I have narrowed down the range for the introduction of this crash, and the range that the crash disappeared.

Introduction of the crash using attachment 274267 [details]: 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006091212 Minefield/3.0a1
- testcase WFM 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006091221 Minefield/3.0a1
- testcase crashes

Checkins to module PhoenixTinderbox between 2006-09-12 11:00 and 2006-09-12 22:00 :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-12+11&maxdate=2006-09-12+22&cvsroot=%2Fcvsroot



Disappearance of the crashing using attachment 274267 [details]:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007030719 Minefield/3.0a3pre
- testcase crashes

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007030804 Minefield/3.0a3pre
- testcase WFM 

Checkins to module PhoenixTinderbox between 2007-03-07 18:00 and 2007-03-08 05:00 :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-07+18&maxdate=2007-03-08+05&cvsroot=%2Fcvsroot



Because these builds are so old the TalkbackIDs I generated are useless (no symbols), so I haven't included them here. I assume the crashing that I am seeing is what this bug is about [@js_LookupPropertyWithFlags]. 
Sorry I forgot to mention my build id. Here it is: Mozilla/5.0 (Macintosh; U;
Intel Mac OS X; en-US; rv:1.8.1.8pre) Gecko/20071014 BonEcho/2.0.0.8pre
ID:2007101403

I also run attachment 274267 [details] multiple times. The cpu goes up to nearly 100%
usage but no crash happens.
Thanks for digging out a smaller regression range, Steve!
That made it a lot easier to back out possible candidates for this regression.

After I backed out the patch for bug 352312, I no longer seem to crash with the testcase.
Depends on: 352312
Blocks: 352312
No longer depends on: 352312
Reduced testcase for the js shell would help. Igor, thanks for taking this -- I hope you can help since I'm still not fully back at work.

/be
The test case does not crash on Linux either. I will try to run it on a Windows machine.

In any case it is really nice that the bug behind the regression was identified.
Blocks: 400897
It's getting increasingly difficult to minimize stuff further as it seems less and less likely to crash when it is smaller.
This seems to crash for me after a while when I have the js console open and the browser minimized (but this may all be superstition).
Ok, I managed to squeeze it a bit further.
This one repeatedly calls the code that seems to cause the crash. If this doesn't crash you'll get the slow script warning instead.
Attached patch patch? — — Splinter Review 
This seems enough to fix the crash.
It's probably breaking something else, I guess, but probably not nearly as bad as crashing, I would say.
Attachment #293884 - Flags: review?(igor)
Comment on attachment 293884 [details] [diff] [review]
patch?

I am not the right person to ask to review the change.
Attachment #293884 - Flags: review?(igor) → review?(brendan)
Comment on attachment 293884 [details] [diff] [review]
patch?

Not the right patch (op = JSOP_NAME duplication aside) -- chatting with Martijn it seems to me there's an impurity lurking that this patch helps hide. Need to purify or valgrind the crashing case, or even a "working" case.

/be
Attachment #293884 - Flags: review?(brendan) → review-
I have purify installed now, but I don't really know how to get useful info out of that.
But I now managed to crash while under gdb, this is the stack trace of the crash while running partly minimized testcase3.
mrbkap reminded me that this is fixed on trunk AFAIWCT, and suggested one of the fixes from gavin@picsel.com might be wanted on the 1.8 branch. I think that's one of these bugs:

bug 364836
bug 381779
bug 384809
bug 393537

but I'm not sure. Cc'ing Gavin. Thanks for the backtrace and help, Martijn!

/be
Whiteboard: topcrash #14 → topcrash #14, DUPEME
(In reply to comment #54)
> mrbkap reminded me that this is fixed on trunk AFAIWCT, and suggested one of
> the fixes from gavin@picsel.com might be wanted on the 1.8 branch. I think
> that's one of these bugs:
> 
> bug 364836
> bug 381779
> bug 384809
> bug 393537
> 
> but I'm not sure. Cc'ing Gavin. Thanks for the backtrace and help, Martijn!
> 
> /be
> 

Some of these are already applied to the 1.8/1.8.1 branches, but for those that aren't bug 381779 is an optimisation so maybe not all that important in terms of this bug. Bug 384809 (or parts of it) are probably worth applying to avoid problems in OOM cases. In relation to this bug OOM doesn't seem to be the issue though.

The stack trace in comment 53 made me wonder about this possibility:

mark = arena_mark(..)
...do some big arena allocations...
arena_release(mark)

Is it possible for the 'do some big arena allocations' stage to perform a realloc that moves the base pointer of the arena? If so that would suggest that the call to 'release' could lead to problems if the arena is used again (since it would restore a stale pointer I think). I am probably talking nonsense though since I would have expected this to have shown problems quite readily if it were possible.

Sorry for the delay. The patch for bug 384809  and the patch for bug 381779 don't help. And like Gavin said in comment 55, the patch for bug 364836 and the patch for bug 393537 are already in the 1.8.1 tree.
Since we have less of a handle on this than I thought at the time I guess this shouldn't block 1.8.1.12 release.
Flags: blocking1.8.1.12+ → blocking1.8.1.12?
Priority: -- → P2
Not blocking 1.8.1.12
Flags: blocking1.8.1.12? → blocking1.8.1.12-
js_LookupPropertyWithFlags is topcrash #10 in 2.0.0.12 :(

https://bugzilla.mozilla.org/attachment.cgi?id=274267 is still crashing for me with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13pre) Gecko/20080212 BonEcho/2.0.0.13pre ID:2008021203

Should it block 2.0.0.13 ?
Flags: blocking1.8.1.13?
Igor: is there any hope for beating down this branch topcrash?
Flags: blocking1.8.1.13? → blocking1.8.1.13-
No topcrasher on OS X and Linux but there are also some crash reports => All/All.
OS: Windows XP → All
Hardware: PC → All
The testcase attached to this bug is only crashing on branch.
I guess a good way would be to verify the regression range in comment 19.

Download the builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (Check for the builds with 'mozilla1.8' in the directory name)
Whiteboard: topcrash #14, DUPEME → topcrash #14, DUPEME [firebug-p1]
igor: were you ever able to repro this in windoze?
Flags: blocking1.8.1.18?
As much as it would be great to fix, it's even less of a blocker than before now that we've shipped Firefox 3 without this crash.
Flags: blocking1.8.1.18? → blocking1.8.1.18-
FF2 EOL, not a Firebug priority
Whiteboard: topcrash #14, DUPEME [firebug-p1] → topcrash #14, DUPEME
This goes back to the pool.
Assignee: igor → general
Keywords: testcase
Whiteboard: topcrash #14, DUPEME → topcrash #14, DUPEME; wfm 1.9.0
top 20 topcrash for Thunderbird 2 
if stack is a match - can we make anything out of the draft patch?

a few samples (lots of crashes have comments)
TB54712292 After a few moments, thunderbird closes without warning, no mater what I do, reading mail, downloading attachment or forwarding mail. This problem start yesterday 20/05/09
TB54577790 checking mail
TB55747402 checking news
TB54474790 returning from sleep
The good news is the testcase https://bugzilla.mozilla.org/attachment.cgi?id=274267 still crash in Firefox 2.0.0.20.

Clicking in the page to select some text should it make it crash if it doesn't crash by reloading the page automatically.
I got the talkback  TB55825067W but it sadly doesn't crash anymore at js_LookupPropertyWithFlags :(

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB55825067W

-------------

Stack trace:

msvcrt.dll + 0x372e3 (0x77c472e3)
SprintPut  [mozilla/js/src/jsopcode.c, line 410]
js_DecompileCode  [mozilla/js/src/jsopcode.c, line 4200]
js_DecompileFunction  [mozilla/js/src/jsopcode.c, line 4398]
JS_DecompileFunction  [mozilla/js/src/jsapi.c, line 4192]
fun_toString  [mozilla/js/src/jsfun.c, line 1543]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1387]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3966]
js_Execute  [mozilla/js/src/jsinterp.c, line 1648]
JS_EvaluateUCScriptForPrincipals  [mozilla/js/src/jsapi.c, line 4334]
nsJSContext::EvaluateString  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1138]
nsScriptLoader::EvaluateScript  [mozilla/content/base/src/nsScriptLoader.cpp, line 779]
nsScriptLoader::ProcessRequest  [mozilla/content/base/src/nsScriptLoader.cpp, line 676]
nsScriptLoader::DoProcessScriptElement  [mozilla/content/base/src/nsScriptLoader.cpp, line 609]
nsScriptLoader::ProcessScriptElement  [mozilla/content/base/src/nsScriptLoader.cpp, line 361]
nsHTMLScriptElement::MaybeProcessScript  [mozilla/content/html/content/src/nsHTMLScriptElement.cpp, line 663]
nsHTMLScriptElement::BindToTree  [mozilla/content/html/content/src/nsHTMLScriptElement.cpp, line 456]
nsGenericElement::AppendChildTo  [mozilla/content/base/src/nsGenericElement.cpp, line 2876]
HTMLContentSink::ProcessSCRIPTTag  [mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 4181]
HTMLContentSink::AddLeaf  [mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 3047]
HTMLContentSink::AddHeadContent  [mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 2998]
CNavDTD::AddHeadLeaf  [mozilla/parser/htmlparser/src/CNavDTD.cpp, line 3616]
CNavDTD::HandleToken  [mozilla/parser/htmlparser/src/CNavDTD.cpp, line 955]
CNavDTD::BuildModel  [mozilla/parser/htmlparser/src/CNavDTD.cpp, line 458]
nsParser::BuildModel  [mozilla/parser/htmlparser/src/nsParser.cpp, line 2169]
Did I just hit bug 400532?

Bug 424558 got a similar stack, and have a wip patch in it!

CCing Mats Palmgren
should this be WFM?   2.0 is no longer supported, and I don't see the crash in 3.5.x.
That is already 'Version: 1.8 Branch', so I don't see the point of WFM it.

Perhaps clear the 'Importance' and 'Target Milestone' ?
or mark as won't fix?
Only mark it WONTFIX if the Linux distros don't want this fixed for their Firefox 2 and 1.5 releases *and* if it doesn't affect Thunderbird. Can you confirm those two things are true?
Summary: Crash [@js_LookupPropertyWithFlags] (sometimes view source?) → [1.8 branch] Crash [@js_LookupPropertyWithFlags] (sometimes view source?)
Is there anything that is keeping this from being a WONTFIX now?
Have you done anything that was said in comment 78?
WFM on trunk.  People using ancient branches (Linux distros and Thunderbird) can track branch status using branch status flags.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
See Also: → https://launchpad.net/bugs/73857
Crash Signature: [@js_LookupPropertyWithFlags]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: