MASTER firefox crashed [@ XPC_WN_Helper_NewResolve] [@ js_LookupPropertyWithFlags]

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-...

(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. ***

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

> 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.

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.

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?

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!

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?

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...

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)

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

Created an attachment (id=274267)
testcase from François

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...

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).

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

Why is this QAwanted? We have a reduced test case for this.

It was added with comment 14 and can be removed now.

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?

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.

No topcrasher on OS X and Linux but there are also some crash reports => All/All.

There are even listed a lot of crashes for trunk builds with the similar top frame:
http://crash-stats.mozilla.com/report/list?range_unit=months&query_search=signature&query_type=contains&branch=1.9&signature=js_LookupPropertyWithFlags&query=js_LookupPropertyWithFlags&range_value=1

I think the version field should be updated to Trunk.

The testcase attached to this bug is only crashing on branch.

Another one:

TB41826697Z

More:

TB41872185Y

Are these related to this bug?

https://bugzilla.mozilla.org/show_bug.cgi?id=418116
https://bugzilla.mozilla.org/show_bug.cgi?id=404787

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41575054W
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41575056G
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41575058X
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41707236E
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41709732W
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41710258Z
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41826697Z
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB41872185Y

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)

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

I have discovered that disabling SwitchProxy Tool 1.4.1 will make this problem ( actually the problem I described in https://bugzilla.mozilla.org/show_bug.cgi?id=418116 ) disappear.

#39 crasher for 2.0.0.14 - all comments refer to getting mail

igor: were you ever able to repro this in windoze?

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.

FF2 EOL, not a Firebug priority

This goes back to the pool.

*** Bug 485680 has been marked as a duplicate of this bug. ***

rare, but also exists on trunk. all 3 from the past month are 3.0b3pre
bp-16272751-900d-424d-a5f9-9b3522090503

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?

  gebozini, can you still reproduce your problem using firefox 3.5?

I'm not so sure bug 418116 is properly a dupe of this. But I haven't compared stacks

  gebozinis?

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.