Closed Bug 206199 Opened 17 years ago Closed 16 years ago

redeclaration of const in script containing try block(s) causes UMR+crash - e.g. MozMail with Enigmail (0.82.5 and older) results in crash on startup

Categories

(Core :: JavaScript Engine, defect, P1, critical)

x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla1.7alpha

People

(Reporter: finlay_bugzilla_2003, Assigned: brendan)

References

Details

(Keywords: crash, fixed1.4.2, Whiteboard: only seen with 3rd-party mail extensions installed)

Attachments

(6 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507

In 1.4b (not 1.4a or earlier) the mail client regularly crashes on startup. 
This seems unrelated to whether I've already opened a browser window, or to
whether I've established a dialup connection (mail servers are all accessed over
dialup).

Incidents:
TB20213764H
TB20209157Q
TB20209092M
TB20206049X
TB20201907G
TB20193362Z



Reproducible: Always

Steps to Reproduce:
Doesn't happen all the time - maybe 50% ?

Just bring up the mail client and it happens.

Actual Results:  
crash

Expected Results:  
not crash

I don't think this is related to bug #142615, which is the only mail crash on
startup bug I can find in bugzilla.  This problem is new in test release 1.4b -
1.3, 1.4a were both fine.
Crashes regulary on Windows 2000 (SP5), too.

Mozilla version:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030514

Happens with no visible reasons, but happens regulary!
note: this _doesn't_ happen in 1.5 branch:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030605 is fine.
Have been seeing this since around 1.4b, can't recall about 1.4a
Crashes both with Window -> Mail & Newsgroups and pressing Ctrl+2, not regularly
but when opening mail with some unsaved links/forms in browser it's like playing
Russian roulette lately ;/

WinXP
rv:1.5a Gecko/20030604
TB20980406G
TB21182515K
TB20807207M

rv:1.4b Gecko/20030516
TB20665464H
TB20467894E
TB20426330Q

Upgrading to 20030619 nightly trunk now.
workaround:  the only thing that seemed to reliably avoid the problem was to
open all of the other mozilla-suite programs (browser, chatzilla, composer)
first, before risking opening the mail client.  If this is reproduceable, then
one can imagine the bug might be either a dll init or library init issue.
It's even crashing with rv:1.5a Gecko/20030619
TB21275371Z

Event viewer says:
Faulting application mozilla.exe, version 1.5.20030.61904, faulting module
js3250.dll, version 4.0.0.0, fault address 0x0001c536.
I've had this only once since upgrading to 1.5a0605, but Tarmo still does, even
on a later version.  So the version of mozilla alone may not be the cause.

js3250.dll is part of the javascript subsystem.  Perhaps the crash is due to the
mail client starting up when the highlighted mail contains an html+javascript
part (more likely some _specific_ kind of javascript page)?   I get enough
spam/virii with that characteristic for that to have been my problem.

Tarmo - is there such a javascript mail in your inbox?
20030623 crashed too on Ctrl+2: TB21305182M

Finlay McWalter: Nope, I don't have any HTML in the default accounts inbox and
also using View -> Message Body As -> Plain Text. Since it crashes even before
the MailNews window is displayed this can't be the case AFAIK.

Used addons:
enigmail-0.75.0.xpi
enigmime-0.75.0-win32.xpi
livehttpheaders-0.6.xpi
mng-windows.xpi
mozgest_0_3_5_1.xpi
prefbar-2.2.1.xpi
smoothwheel-v0.3.xpi
up.xpi

The start & close MailNews after browser start workaround seems to be doing the
trick so far though :)

I fear that this bug is probably in  1.4 final too :/
woah... that's a lot of extensions.

could you try uninstalling, deleting the mozilla folder, and then reinstalling,
and see if you can still reproduce the crash?  if you can't reproduce it, put
the addons back gradually and see if the crash comes back - if so, it may be a
bug in an extension.

Finlay - were/are you using any addons?

this WFM with the 1.4 RCs on win2k.
I have no addons, but it crashes somtimes anyway... I just use full Mozilla
install... I dont like it but I will try reinstalling everything... I allways
use installing new version without uninstalling previous.
Ouch, forgot that I'm using addons:

enigmail-0.75.0.xpi
enigmime-0.75.0-win32.xpi
With regard to plugins:  

my previous 1.4b install (on which the bug is based) had the then-current
versions of enigmail and enigmime (sorry, I've zapped the install since, so I
don't know their version numbers - I figure someone with access to the TB
database can tell for sure).  No other plugins.

my current 1.5a install has the current 0.75.0 versions of enigmail and
enigmime, as Tarmo, but no other plugins.  I don't get the crash anymore.

This should be confirmed.
Does it happen after you upgrade to the Enigmail release for Moz 1.4RCx
(enigmail 0.76.1)?
WinXP rv:1.5b Gecko/20030731 trunk nightly

First one on "mozilla.exe -mail -nosplash" others with Ctrl+2:
TB22746811K
TB22746799E
TB22730070M
TB22665757Q
TB22608575G
TB22607548Z

Event Log says always that faulting module is js3250.dll, perhaps someone could
dissect some of them TB data packs and find out WTF?

WinXP rv:1.5b Gecko/20030814 that I've upgraded to today has already once
crashed the same way, no TB because mozilla-win32-talkback.zip in nightly
directory was full of chr(0) only.

Skin doesn't matter AFAIK, were using IE sking previously when it crashed,
Classic now and still the same deal.

I'll try to reproduce it with clean install and new profile soon.

Addons then and currently (not 100% sure that versions were the same though):
enigmail-0.76.4.xpi
enigmime-0.76.3-win32.xpi
flashblock-0.1-modified.xpi
livehttpheaders-0.6.xpi
mng-windows.xpi
mozgest_0_3_5_1.xpi
prefbar-2.2.1.xpi
smoothwheel-v0.32.xpi
textplain-0.3.2.xpi
up.xpi
Keywords: crash, stackwanted
For me this Problem started with 1.5, pls. see bug 209084

Can someone decide whether alll these Mail-Crash-Bugs should be worked under one
bug No.?

Rainer
Blocks: 209084
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 209084 has been marked as a duplicate of this bug. ***
Duped Talkback incidents from bug 209084:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030611:

TB20951773Z
TB20951524W
TB20951303E

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030828:

TB23185606K 
TB 23185583M


A number of those reporting #206199 seemed to be running enigmail and sometimes
enigmime (I did at the time of original posting).  I haven't yet seen anyone
reporting this condition who wasn't (I think!).

Those reporting #209084 don't say either way.  If any of the #206199 folks are
reading - were/are you running enigmail and enigmime?
drok. typo - should read "if any of the #209084 folks are reading". sorry.
Flags: blocking1.5?
brendan, stack look familiar?

from talkback..

Stack Signature  	js_Interpret 8eb1e58c
Email Address 	RainerBielefeldNG@BielefeldUndBuss.de
Product ID 	MozillaTrunk
Build ID 	2003082804
Trigger Time 	2003-08-30 00:59:42
Platform 	Win32
Operating System 	Windows 98 4.10 build 67766446
Module 	JS3250.DLL
URL visited 	MOZILLA crash
User Comments 	And again crash wen I try to open MAIL from the browser WINDOW
Trigger Reason 	Access violation
Source File Name 	c:/builds/seamonkey/mozilla/js/src/jsinterp.c
Trigger Line No. 	2224
Stack Trace 	
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2224]
js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 1057]
JS_ExecuteScript [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3386]
nsJSContext::ExecuteScript
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1022]
nsXULDocument::ExecuteScript
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 3444]
nsXULDocument::LoadScript
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 3230]
nsXULDocument::ResumeWalk
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 2975]
nsXULDocument::EndLoad
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 757]
XULContentSinkImpl::DidBuildModel
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULContentSink.cpp, line
461]
nsExpatDriver::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsExpatDriver.cpp, line 1035]
nsParser::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 1259]
nsParser::ResumeParse [c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp,
line 1831]
nsParser::OnStopRequest
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 2491]
nsJARChannel::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 673]
nsCOMPtr_base::assign_with_AddRef
[c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 71]
nsInputStreamPump::OnStateStop
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 484]
nsInputStreamPump::OnInputStreamReady
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 325]
nsInputStreamReadyEvent::EventHandler
[c:/builds/seamonkey/mozilla/xpcom/io/nsStreamUtils.cpp, line 117]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 672]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 610]
_md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line
1413]
KERNEL32.DLL + 0x24407 (0xbff94407)
0x00658b66 
I still see problems in
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030827
Please also see my comments in bug 209084

Actually I can start mailnews, but from  time to time it crashes immediately
when I select a special newsgroup.

I have installed all addons as listed in bug 209084, excepted Mnenhy.

Funny thing: after I opened NG 1 time with 1.4 final, _this_ NG can eb opened
again with my 1.5, but it will find another one to crash :-(

So unfortunately 1.5 still is completely unusable  for me.

Same problem as reported or anothr crash problem?

I will add a Talkback!

Rainer
Attached file Talkback
Talkback
Problem from  Comment #21  Rainer Bielefeld  2003-09-08 can not be solved by
deleting "XUL.mfl". Mailnews still crashes at the same NG as before.

Rainer
Still happening?  A fix went in on 9/3:

jsemit.c
revision 3.89
date: 2003/09/03 02:10:38;  author: brendan%mozilla.org;  state: Exp;  lines: +20 -6
Fix js_FinishTakingSrcNotes edge-case (bug 216320, r=shaver, a=asa).

However, the stack here looks more like other undiagnosed talkback crashes than
it does the stack you would get for bug 216320.  Cc'ing Phil in case he can id a
dup.

/be
Rainer: the stack trace you posted in Comment #22 has Build Identifier
2003082704. Is the crash still occurring with an up-to-date build?
Hi Phil,

I tested Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030910 (more or
less "clean installation" 3 days without problem.

I will now install additional addons with influence to "mail"

Rainer
It's still on nightly trunk rv:1.5b Gecko/20030911

TB23571102Q on Ctrl+2

And in Eventlog as usual:
Faulting application mozilla.exe, version 1.5.20030.25568, faulting module
js3250.dll, version 4.0.0.0, fault address 0x0001ad24.

All the comment #14 extensions plus:
forcect-0.2.xpi
jslib_current_static-0.1.83.xpi
For me et seems to work with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b)
Gecko/20030910 and addons "Mnenhy" and "Message Finder", but as comment From
Tarmo  Järvalt  2003-09-13 10:19 shows, we have no "all clear" for this problem.

Rainer
And now I had it again (unable to open with "-mail", crashes immediately) with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030910
and addons "Mnenhy" and "Message Finder" (I don't know whether addons have to do
with crash).

I found in JS-console, when I started 1.4final with -mail:
Error: redeclaration of const MSG_FOLDER_FLAG_TRASH
Source File: chrome://messenger/content/commandglue.js
Line: 1

I sent a Talkback: TB23890532E (I can also attach if required)

Problem was "repaired" by 1 time opening 1.4final with "-mail"

Rainer
This unfortunately appears to be a characteristic of this bug - that it seems to
"come and go" for multiple reporters.  We've not managed to come up with a
deterministic testcase either for reproducing it or for avoiding it.  There's a
fairly strong correlation between it and the presence of the enigmail/enigmime
plugins, and a few people (myself included) informally report that starting
other mozilla components before mail seems, sometimes, to avoid the problem. 
Unfortunately this nondeterminism means that, even if a supposed fix is
checked-in, the disapearance of the crash for one or two users won't necessarily
confirm that the fix was sufficient.
Need a stack, ideally with valid line numbers.  Anyone able to look up the
latest talkback ids (I'm not inside the firewall ATM), please attach stacks here
with symbols and linenos.

/be
*** Bug 219211 has been marked as a duplicate of this bug. ***
I can confirm that disabling enigmail "fixes" this problem, at least under the
latest nightly Thunderbird builds.
Attached file stacks
These were the retrievable stacks.  The others came up blank -- probably too
old.
For that first stack in the "stacks" attachment, js_AllocStack, what were the
registers?  I wonder if fp->script is non-null  but invalid, so that the load of
fp->script->depth at line 381 in jsinterp.c faulted.  How could fp->script be
bad?  I have no idea, but it would help to know if this stack involved a browser
window or a mail window.  Anyone know how to tell?

dbaron, mscott, could use your help on the registers and on the "is this a mail
window" questions.

/be
Still the same, It works for some time, than crash!

Today I had again the situation that MOZILLA MAIL crashes when I try to start it.

JS-Debug-Messages in Javascript console:
Error: redeclaration of const MSG_FOLDER_FLAG_TRASH
Source File: chrome://messenger/content/commandglue.js
Line: 1

Error: redeclaration of const gcsMnenhyPackage
Source File: chrome://mnenhy/content/mnenhy.js
Line: 1

Rainer
In incident 23571102, the registers were:

x86 Registers:
EAX:  0012f938 	EBX:  041181f8  ECX:  0012f9a8  EDX:  00000001
ESI:  017310d8 	EDI:  00000003 	ESP:  0012fff8 	EBP:  00000000
EIP:  00000000 	cf pf af zf sf of IF df nt RF vm   IOPL: 0
CS:  001b  DS:  0023  SS:  0023  ES:  0023  FS:  003b  GS:  0000

There's no assembly since EIP is null.



In incident 23185583, they are:

x86 Registers:
EAX:  2f302e30 	EBX:  00000002 	ECX:  10262823 	EDX:  02a7b550
ESI:  00000007 	EDI:  02df132c 	ESP:  0065f600 	EBP:  0065f748
EIP:  6105d31b 	cf PF af zf sf of IF df nt RF vm   IOPL: 0
CS:  017f  DS:  0187  SS: 0187  ES:  0187  FS:  0f27  GS:  0000
Code Around the PC:
6105d31b dd00             fld     qword ptr [eax]        <== EIP at crash
6105d31d 8b4dec           mov     ecx,[ebp-0x14]
6105d320 b80000f07f       mov     eax,0x7ff00000
6105d325 dd5dc4           fstp    qword ptr [ebp-0x3c]
6105d328 23c8             and     ecx,eax
6105d32a 3bc8             cmp     ecx,eax
6105d32c 750f             jnz     6105d33d
6105d32e 837de800         cmp     dword ptr [ebp-0x18],0x0
6105d332 752e             jnz     6105d362
6105d334 f745ecffff0f00   test    dword ptr [ebp-0x14],0xfffff



In incident 23571102, the EIP was also null.
If we get a fix quickly we will try to take it for 1.5 but it may have to fall
off the list if it doesn't happen soon.
Flags: blocking1.5? → blocking1.5+
Is enigmail or any other 3rd-party app required to encounter this crash? 
see also bug 214043

> Is enigmail or any other 3rd-party app required to encounter this crash?

yes.  everyone that has reported this crash has enigmail or another 3rd-party app.
Flags: blocking1.5+ → blocking1.5-
slogging though a bunch of talkback data I see that the stack signatures
js_Interpret 8eb1e58c 	
 
with comments like

And again crash wen I try to open MAIL from the browser WINDOW

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030828 rather often
crashes when: I have a browser window open open another URI in background in a
new TAB while loading new URI open MAIL with Mail.button at the bottomn of the

browser-window. I see this with all 1.5 Versions No Problems with 1.4


Also all have the platform listed as:  ->>  Windows 98 4.10 build 

those with access to the data base see...
http://climate.iwebsys.netscape.com/customreports/quicksearch.cfm?search=stacksig&item=js_Interpret%208eb1e58c&type=contains&vendor=&product=&platform=
I confirm the same problem on 1.4 (official release) on WinMe. The only add-on
I have at the moment is enigmail (0.76 I think) and I never encountered the
problem before I installed enigmail. However, enigmail appeared to work some
time without problems since I never made the link...

I also have 1.4 on a RedHat Linux 7.3 (official RPM release) together with
enigmail and encounterd no similar problems. However, I selected the option to
start the mailclient by default but always get the navigator. This could be
offcourse the reason why the problem does not appear on linux if it's a
initialization issue.
Also appears using Thunderbird 0.3 on Windows XP.  I do not have Enigmail 
installed though other extensions are present: mozCalc, Offline Support, 
Preferential, Quote Colors, Get All Messages (disabled), addressContext and 
QuickNote.

Work around: The only way I was able to get into mail yesterday was through 
the Profile Manager (which uses the same executable with the '-p' command line 
option).  Other proposed fixes, such as removing the XUL.mfl file had no 
effect.

Incidents: How do I find the talkback identifiers for inclusion in this report?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031028


TB24928528Z

my Add-on: 
      quicknote
      preferential
      livehttpheaders
      messageidfinder
      diggler
      linky
      mnenhy
      moztweak
      mozex


OS:All ?
You can get Talkback IDs by running the talkback program, which should be in the
components directory.

I am also experiencing this crash on WinXP with Mozilla 1.5 final release. I
have at least Enigmail extension installed. If I launch Chatzilla, and then try
Mail, I get crash, but it works the other way around.

Talkback IDs:

TB24941208G
TB24941111X
No longer blocks: 209084
Flags: blocking1.6b?
Incident ID 24941208
Stack Signature 	js_AllocStack 655f83e1
Product ID 	MozillaTrunk
Build ID 	2003100716
Trigger Time 	2003-10-30 09:50:26
Platform 	Win32
Operating System 	Windows NT 5.1 build 2600
Module 	js3250.dll
URL visited 	
User Comments 	1. Launch Mozilla, homepage netscape.com, open a few links in
tabs. 2. Launch Chatzilla from bottom left icon, connecting automatically to
#mozilla and #chandler 3. Launch Mailnews from bottom left icon -> CRASH
Trigger Reason 	Access violation
Source File Name 	c:/builds/seamonkey/mozilla/js/src/jsinterp.c
Trigger Line No. 	388
Stack Trace 	
js_AllocStack [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 388]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 925]
js_InternalGetOrSet [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 979]
js_GetProperty [c:/builds/seamonkey/mozilla/js/src/jsobj.c, line 2660]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2695]
js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 1057]
JS_ExecuteScript [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3386]
nsJSContext::ExecuteScript
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1022]
nsXULDocument::ExecuteScript
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 3444]
nsXULDocument::LoadScript
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 3230]
nsXULDocument::ResumeWalk
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 2975]
nsXULDocument::EndLoad
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 757]
XULContentSinkImpl::DidBuildModel
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULContentSink.cpp, line
461]
nsExpatDriver::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsExpatDriver.cpp, line 1035]
nsParser::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 1259]
nsParser::ResumeParse [c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp,
line 1831]
nsParser::OnStopRequest
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 2491]
nsJARChannel::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 673]
nsCOMPtr_base::assign_with_AddRef
[c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 71]
nsInputStreamPump::OnStateStop
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 484]
nsInputStreamPump::OnInputStreamReady
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 325] 
Incident ID 24941111
Stack Signature 	js_AllocStack e72f92f6
Product ID 	MozillaTrunk
Build ID 	2003100716
Trigger Time 	2003-10-30 09:48:59
Platform 	Win32
Operating System 	Windows NT 5.1 build 2600
Module 	js3250.dll
URL visited 	
User Comments 	
Trigger Reason 	Access violation
Source File Name 	c:/builds/seamonkey/mozilla/js/src/jsinterp.c
Trigger Line No. 	388
Stack Trace 	
js_AllocStack [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 388]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 925]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3540]
nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 269]
nsXPCWrappedJSClass::GetRootJSObject
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 598]
nsXPCWrappedJS::GetNewOrUsed
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 219]
XPCConvert::JSObject2NativeInterface
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 1134]
nsXPConnect::WrapJS
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/nsXPConnect.cpp, line 588]
nsJSUtils::ConvertJSValToXPCObject
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSUtils.cpp, line 125]
GlobalWindowImpl::GetObjectProperty
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 4289]
nsContentTreeOwner::SetStatus
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 349]
nsWebShell::OnOverLink
[c:/builds/seamonkey/mozilla/docshell/base/nsWebShell.cpp, line 725]
nsGenericElement::TriggerLink
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 3105]
nsGenericHTMLElement::HandleDOMEventForAnchors
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1568]
nsHTMLAnchorElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp,
line 354]
nsEventStateManager::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2520]
nsEventStateManager::GenerateMouseEnterExit
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2646]
nsEventStateManager::PreHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 401]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6208]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6138]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2299]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 305]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2042]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 79]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1054]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1071]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5193]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5448]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 3962]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1334]
USER32.dll + 0x3a50 (0x77d43a50)
USER32.dll + 0x3b1f (0x77d43b1f)
USER32.dll + 0x3d79 (0x77d43d79)
USER32.dll + 0x3ddf (0x77d43ddf)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 484]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1306]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1672]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1694]
WinMainCRTStartup()
kernel32.dll + 0x214c7 (0x77e814c7) 
please see these, too:
http://bugzilla.mozilla.org/show_bug.cgi?id=220287
http://bugzilla.mozilla.org/show_bug.cgi?id=206199

On every 3..~15 th start TB 0.3 crashes (on WinXP, installed in a clean
directory, enigmail installed). Deleting XUL.mfl fixes it (temporarily) for me.
(from comment 45)  Heikki, I do not have the talkback application available.  
Must not be part of the Thunderbird 0.3 Zip file.  I suspect my errors are not 
getting sent in but have no way to confirm.

About all I can copy from the error dialogues is:
AppName: thunderbird.exe	 AppVer: 1.5.20031.1319	 ModName: js3250.dll
ModVer: 4.0.0.0	 Offset: 0001bde0

Not sure how much good this does: js3250 appears to be a large module.

(from comment 48)  Olaf, I think you meant bug 219598 instead of 206199 in 
your second "see also" reference.
(from comment 49)
> I think you meant bug 219598 instead of 206199 (self-ref).

Yep, sorry.
Whiteboard: only seen with 3rd-party mail extensions installed
How reproducable is this with enigmail installed?  Could someone describe steps
to reproduce the crash starting from a clean install?  (Do you need to just
install the extension and run mozilla -mail, or is some configuration of the
extension or setup of accounts required?)
adding patrick.brunschwig@gmx.net who is listed at mozdev as the contact for
enigmail.
Q."How reproducable is this with enigmail installed?"

A. I don't believe anyone has figured out a "how to reproduce" method, I'm afraid. 

It seems to strike a given user, for reasons we don't understand. Once striken,
someone seems to suffer from it intensely for a while, until some other
circumstance (equally enigmantic, I'm afraid) happens, at which point it clears
up  pretty much totally.  Enigmail seems to be the only common factor (but
correlation is not causation).  Other than that, there doesn't seem to be
commonality - people don' report having a specific skin, specific email
(javascript, encrypted, whatever) in their inbox, or anything else we can think
of.  No-one seems to know what they did to make the condition arise, or what
they did to make it cease.

Bummer, huh? ;(
It's really strange, as there seems to be nothing reproducibe. All I can say is
that deleting XUL.mfasl (or XUL.mfl) makes the bug go away, at least for
starting Mozilla once.

The only thing I can say for sure is that the chances to be affected from this
bug grows if you install enigmail -- even if you don't configure/use it.
My mozilla mail crashed the same way.
I have no enigmail installed, but I have Mnenhy installed.
The bug appeared on two mozilla profiles (Crash on startup more than half the
time) when I upgraded from 1.4 to 1.5beta and resintalled Mnenhy (did the
upgrade and Mnenhy resintallation the same day).
Now it seems to have disapeared on these two accounts at the same time.

Hope this helps
My 
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.5) Gecko/20031007
with several addons and plugins has been running for some weeks without this
crash problem, when I installed the mozedv "Message Finder" from 
<http://messageidfinder.mozdev.org/>

MOZILLA now is still running for app. 3 weeks without "crash problem".

Tomorrow I will add "mnenhy" from <http://mnenhy.mozdev.org/>

and I will see what will happen.

Rainer
Flags: blocking1.6b? → blocking1.6b-
UserAgent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6a) Gecko/20031103
MultiZilla/1.5.0.4e

This looks like something manipulated by an extension (Mnenhy, in my case), such
as chrome.rdf.

Steps to reproduce:

    1. Install Mnenhy
    2. Exit Mozilla
    3. Restart Mozilla from MailNews
    4. Splash screen comes up for a few seconds, then exits; program crash
    5. Start Mozilla Navigator
    6. Splash screen comes up, then Navigator loads
    7. Click MailNews icon or select Tools | MailNews
    8. MailNews opens normally

Reinstalled Mnenhy per latest comments here. Here's what I got:

    1. Re-installed Mnenhy (on top of working Mnenhy install)
    2. Exited Mozilla
    3. Restarted Mozilla from MailNews
    4. Splash screen came up for a few seconds, then exited; program crash
    5. Went into mozilla\chrome and renamed mnenhy.jar to mnenhy.ja_
    6. Restarted Mozilla from MailNews
    7. Splash screen came up for a few seconds, then MailNews opened (chrome
messed up & no window interiors visible)
    8. Exited Mozilla
    9. Went into mozilla\chrome and renamed mnenhy.ja_ to mnenhy.jar
   10. Restarted Mozilla from MailNews
   11. Splash screen came up for a few seconds, then MailNews opened fine
   12. Exited Mozilla
   13. Restarted Mozilla from MailNews
   14. Splash screen came up for a few seconds, then exited; program crash

It looks like something gets changed when MailNews loads with Mnenhy enabled
which precludes it from properly initializing thereafter. I haven't diff'd the
files to see which file(s) get(s) changed, though.

Lewis
 
Attached file gdb backtrace (obsolete) —
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031211 self build

My Add-on: 
      quicknote
      preferential
      livehttpheaders
      _messageidfinder_
      diggler
      linky
      _mnenhy_

please change this to OS:All 

If you have a gdb stack trace, could you also create a core dump and then
analyse it with gdb (e.g. find null pointers etc.)?
OS: Windows XP → All
>If you have a gdb stack trace, could you also create a core dump and then
>analyse it with gdb (e.g. find null pointers etc.)?

ok how ? 
btw i compile mozilla with -g1, check man gcc whats this means
btw2 and this is not so easy beacause i can't reproduce this now ;-( / ;-)
0x4005a1cf in js_Interpret (cx=0x8ffbb28, result=0xbfffefb8) at jsinterp.c:2155

/mnt/4/cvs2/mozilla/js/src/jsinterp.c:2155:80088:beg:0x4005a1cf

2150		 rval = FETCH_OPND(-1);
2151		 lval = FETCH_OPND(-2);
2152		 JS_ASSERT(!JSVAL_IS_PRIMITIVE(lval));
2153		 obj  = JSVAL_TO_OBJECT(lval);
2154		 SAVE_SP(fp);
>>2155		   CACHED_SET(OBJ_SET_PROPERTY(cx, obj, id, &rval));
2156		 if (!ok)
2157		     goto out;
2158		 sp--;
2159		 STORE_OPND(-1, rval);
2160		 break;
Attachment #137648 - Attachment is obsolete: true
I finally managed to get several such crashes with a non-stripped debug version
of Thunderbird 0.4 (Linux), and I could attach a debugger to it. 
I always see the following stack:

jsapi.c: JS_ExecuteScript: script=(some valid pointer)
jsinterp.c: js_Execute: script=0xfffffffc (i.e. invalid pointer!)

the crash occurs in
jsinterp.c: js_Interpret, Line 1929:
obj = JSVAL_TO_OBJECT(propobj->slots[JSSLOT_PARENT]);

propobj seems to point to an invalid address; propobj->map and propobj->slots
are not accessible. Unfortunately, I cannot debug this myself, I have no clue of
the js library :-(
Update: I just found a way to reproduce the crash ca 9 of 10 times. If someone
would be interested in debugging, I could offer ssh access to my PC.
Patrick: thanks, I'm interested.  Look for me in irc.mozilla.org, brendan.

/be
Hello,
same thing here with Mozilla 1.6b on WinNT 4.0 SP6a and Enigmail 0.82.5.
Frequent crash on startup of the mail component. Sorry, no talkback avail.

Bye
  Rainer Tammer
I've been busy with newborn (still am), was going to reconnect with Patrick via
IRC (he kindly set up an ssh connection via which I tried to reproduce and debug
a bit on his system).  But valgrind input is much appreciated -- thanks, dbaron.

The assertion is benign, although it was introduced with XUL fastload (which
came after chrome JS fastload, the first incarnation of fastload), and could be
fixed with some more work in content/xul/document/src/.  Cc'ing jrgm, my old
fastload buddy.

So, http://lxr.mozilla.org/mozilla/source/js/src/jsinterp.c#4246 seems not to be
the right line, if current source is used.  Any idea where the pc is when that
first bad load executes?

/be
Assignee: sspitzer → brendan
Status: NEW → ASSIGNED
Component: Mail Window Front End → JavaScript Engine
Priority: -- → P1
Product: MailNews → Browser
Target Milestone: --- → mozilla1.7alpha
Ok, any idea where in SCRIPT_FIND_CATCH_START the UMR might be?

/be
So far reduced it to the line "while (JS_UPTRDIFF(offset_, tn_->start) >=
(jsuword)tn_->length)".  Trying to get farther (I rewrote the line to be 3
lines), but valgrind is slow.  (It's worth noting that in the run I just did I
only saw the first 2 errors -- then startup continued.)
The first one was reading tn_->length, the second was reading tn->start (odd
that they were in different iterations, perhaps?).
Also, FWIW, the errors (when I don't crash) are followed by 

JavaScript error:
chrome://enigmail/content/enigmailCommon.js line 8: redeclaration of const
ENIG_MSG_BUFFER_SIZE
SCRIPT_FIND_CATCH_START is running off the end of the trynotes list because
offset_ (i.e., pc - script->main) is negative (-324, to be exact).
More fall-out from this sequence of developments, over several years:

1.  I design the JS engine to reckon srcnotes from the start of the script.

2.  ECMA requires prolog bytecodes for declarations, which means the script has
a main entry point after the prologs; srcnote offsets start at the main entry
point, not at the beginning of the script's bytecode (script->code, which will
point to prolog bytecodes that come before script->main if the script contains
function and var declarations).

3.  Shaver and I add exception handling support, and the JSTryNote offsets are
likewise measured from script->main.

4.  I add const (from JS2/ES4) and, independently, strict warnings for variable
redeclarations, resulting in errors being reported from prolog bytecodes.

5.  (Not sure of order wrt 4 here) McCabe et al. add errors as exceptions,
causing redeclaration errors to be thrown.

6.  I fix bug 208030 so that srcnote origin is start of prolog, not main entry
point, to relieve complaints about bogus line number 1 given by redeclaration
errors (which become exceptions, but which are not caught typically -- you can't
wrap the prolog of a script in a try block!).  I fail to look for other code
that used script->main as its origin, but that now needs to cope with prolog
bytecodes throwing exceptions.

7.  Enigmail somehow happens to have a const redeclaration *and* a try block
active around the inner script (eval?  dunno, this needs analysis) that contains
the redundant const declaration.  It therefore runs right into the bug unfixed
in 6: JSTryNotes are reckoned from script->main, yet the pc may be lower than
main (in the prolog).

Whew.  Patch soon.  It should go in 1.6.  I'll need testing help.

/be
Oh (yes, I'm sleep-deprived and loving it!), there's no mystery in 7, no need
for more analysis: any script with try blocks and a const redeclaration will run
into this bug, and the trynote lookup will march right off the end of the
script->notes vector.

/be
Attached patch proposed fix (obsolete) — Splinter Review
Essentially a one-line patch (diff -w version next).

/be
Attachment #138134 - Flags: review?(shaver)
Patrick, can you fix the const redeclaration in enigmail?

/be
The fix does not allow a script to catch its own declaration errors.  I think
this is most consistent (as an extension) with ECMA-262; see section 10.2 on
Entering an Execution Context, specifically variable instantiation (which is
error-free in ECMA-262 Edition 3 and before, but which should have errors for
extensions such as const).

Someone who knows the draft Edition 4 stuff please correct me if I am wrong and
const redeclarations should be catchable by the script containing the erroneous
const declaration.

/be
Attachment #138134 - Attachment is obsolete: true
Attachment #138135 - Attachment is obsolete: true
Attachment #138134 - Flags: review?(shaver)
Attachment #138139 - Flags: review?(shaver)
attachment 138134 [details] [diff] [review] fixed the crash and valgrind warnings that I was seeing
I have applied the patch in attachment 138140 [details] [diff] [review] on my source tree: the crash I
could reproduce ca. 9 of 10 times has *finally* gone!

I definitely suggest to have this patch included in the 1.6 release.

I'll fix the redeclaration bug with the next enigmail release (although the
crashes could be seen without enigmail installed as well...).
For those using Enigmail, I have released Enigmail v0.82.6, which should not
have any const redeclarations anymore.
Ok, i've changed the summary to hopefully describe the problem correctly and
flag the relevant EnigMail release.

Hi Phil, as usual this (attachment 138139 [details] [diff] [review]) should run through the regression
suite (and new testcases need to be added). I could probably try to do it
somewhere but I'm low on bandwidth (I'm relocating) and cpu cycles (my boxes are
somewhere in the middle of the continental us).

For reference, here is the xpcshell instance I managed:
mozhack@boffo:~/obj-i686-pc-linux-gnu-qt/dist/bin$ ./run-mozilla.sh ./xpcshell

js> try {
const a=0;
constr =0;
const a=1;
typein:4: TypeError: redeclaration of const a:
typein:4: const a=1;

typein:4: ......^
js> }
typein:5: SyntaxError: syntax error:
typein:5: }

typein:5: ^
js> const a=0;
js> try {
const a=0;
} catch(e){}
Assertion failure: vp >= fp->spbase, at
/mnt/ibm/mozhack/mozilla/js/src/jsinterp.c:2528
./run-mozilla.sh: line 72: 28722 Aborted                 "$prog" ${1+"$@"}

And js shell:
mozhack@boffo:~/mozilla/js/src/Linux_All_DBG.OBJ$ ./js
js> const a=0; try { const a=1; } catch(e){}
typein:1: TypeError: redeclaration of const a:
typein:1: const a=0; try { const a=1; } catch(e){}
typein:1: .......................^
js> const a=0;
js> try { const a=1; } catch(e){}
js> 
js> try { const a=1; } catch(e){}
Assertion failure: JSVAL_IS_OBJECT(rval), at jsinterp.c:1483
Aborted

fwiw
js> build()
built on Aug  4 2003 at 06:26:54
(so js shell wasn't quite current, but that doesn't matter - xpcshell is
tinderboxed so it's current [as of the last time cvs was working...] ignoring
whatever patches I have locally which don't include this one and shouldn't
include any relevant ones).

I'm nominating this for 1.6. brendan has a handle on this and just needs a
review from shaver (or possibly someone else), the fix is small and we don't
want js engine crashers lying around if we know how to fix them.
Flags: blocking1.6?
Keywords: stackwanted
QA Contact: esther → PhilSchwartau
Summary: Mail client crashes immediately on startup - very frequent → redeclaration of const inside try block causes UMR+crash - e.g. MozMail with Enigmail (0.82.5 and older) results in crash on startup
Comment on attachment 138139 [details] [diff] [review]
slightly better fix (no JS_UPTRDIFF dependency)

Yeah, looks good.  (For the record, E-as-E predates const, IIRC.) r=shaver
Attachment #138139 - Flags: review?(shaver) → review+
Fixing summary, which again raises the issue: in JS2/ES4, can you catch an
exception for a redeclaration of a const?  From
http://www.mozilla.org/js/language/es4/formal/parser-semantics.html I see only a
ReferenceError being thrown from the /writeVariable/ semantic procedure, and
only for an attempt to initialize a const more than once.

I'll leave JS2/ES4 compatibility for a future bug, and ask for approval of the
reviewed patch here for 1.6.  Marking blocking1.4.2 as well, since the bug is in
that release.

/be
Flags: blocking1.6?
Flags: blocking1.6+
Flags: blocking1.4.2+
Summary: redeclaration of const inside try block causes UMR+crash - e.g. MozMail with Enigmail (0.82.5 and older) results in crash on startup → redeclaration of const in script containing try block(s) causes UMR+crash - e.g. MozMail with Enigmail (0.82.5 and older) results in crash on startup
Comment on attachment 138139 [details] [diff] [review]
slightly better fix (no JS_UPTRDIFF dependency)

Safe crash fix for 1.4.2 and 1.6.

/be
Attachment #138139 - Flags: approval1.6?
Attachment #138139 - Flags: approval1.4.2?
Comment on attachment 138139 [details] [diff] [review]
slightly better fix (no JS_UPTRDIFF dependency)

a=asa (on behalf of drivers) for checkin to Mozilla 1.6
Attachment #138139 - Flags: approval1.6? → approval1.6+
Fix is in for 1.6 branch and 1.7 trunk -- closing per usual protocol, even
though 1.4.2 remains unfixed.

I opened bug 229756 on the JS2/ES4 incompatibility.

/be
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
has bug 226574 something to do with this issue?
Work around: After creating a new Profile Mozilla crashed anymore.
Comment on attachment 138139 [details] [diff] [review]
slightly better fix (no JS_UPTRDIFF dependency)

a=mkaply
Attachment #138139 - Flags: approval1.4.2? → approval1.4.2+
Can someone put this on the 1.4 branch and mark it fixed1.4.2? or should I do it?
The 1.4 branch has tn_++ rather than ++tn_

Does this matter?

Should I change it to +tn_ or change the patch to use tn_++
I took the new patch
Keywords: fixed1.4.2
It doesn't matter, since nobody was using the result.
What dbaron said, but all else equal, I prefer to sync to trunk; and ++tn_ is
more readable (although most of the old-school C increment-without-value-used
code in the js engine uses post-increment, an homage to the PDP-11).

/be
*** Bug 220287 has been marked as a duplicate of this bug. ***
*** Bug 219598 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.