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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Finlay McWalter]

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.

Comment 1

[Lauris]

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!

Comment 2

[Finlay McWalter]

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.

Comment 3

[Tarmo Järvalt]

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.

Comment 4

[Finlay McWalter]

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.

Comment 5

[Tarmo Järvalt]

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.

Comment 6

[Finlay McWalter]

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?

Comment 7

[Tarmo Järvalt]

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 :/

Comment 8

[Michael Lefevre]

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.

Comment 9

[Lauris]

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.

Comment 10

[Lauris]

Ouch, forgot that I'm using addons:

enigmail-0.75.0.xpi
enigmime-0.75.0-win32.xpi

Comment 11

[Finlay McWalter]

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.

Comment 12

[Sam Katz]

This should be confirmed.

Comment 13

[Daniel Jensen]

Does it happen after you upgrade to the Enigmail release for Moz 1.4RCx
(enigmail 0.76.1)?

Comment 14

[Tarmo Järvalt]

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

Comment 15

[Rainer Bielefeld]

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

Comment 16

[Karsten Düsterloh]

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

Comment 17

[Karsten Düsterloh]

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

Comment 18

[Finlay McWalter]

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?

Comment 19

[Finlay McWalter]

drok. typo - should read "if any of the #209084 folks are reading". sorry.

Comment 20

[chris hofmann]

brendan, stack look familiar?

from talkback..

Stack Signature  	js_Interpret 8eb1e58c
Email Address 	[e-mail]
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 

Comment 21

[Rainer Bielefeld]

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

Comment 22

[Rainer Bielefeld]

Attachment: Talkback

Talkback

Comment 23

[Rainer Bielefeld]

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

Comment 24

[Brendan Eich [:brendan]]

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

Comment 25

[Phil Schwartau]

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

Comment 26

[Rainer Bielefeld]

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

Comment 27

[Tarmo Järvalt]

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

Comment 28

[Rainer Bielefeld]

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

Comment 29

[Rainer Bielefeld]

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

Comment 30

[Finlay McWalter]

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.

Comment 31

[Brendan Eich [:brendan]]

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

Comment 32

[Scott MacGregor]

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

Comment 33

[Simon Morgan]

I can confirm that disabling enigmail "fixes" this problem, at least under the
latest nightly Thunderbird builds.

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stacks

These were the retrievable stacks.  The others came up blank -- probably too
old.

Comment 35

[Brendan Eich [:brendan]]

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

Comment 36

[Rainer Bielefeld]

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

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 38

[Asa Dotzler [:asa]]

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.

Comment 39

[Asa Dotzler [:asa]]

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

Comment 40

[Andrew Schultz]

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.

Comment 41

[chris hofmann]

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=

Comment 42

[Dries Van Dyck]

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.

Comment 43

[drb24]

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?

Comment 44

[Artur Polaczynski]

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 ?

Comment 45

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 46

[Jan Carpenter]

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] 

Comment 47

[Jan Carpenter]

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) 

Comment 48

[Olav Seyfarth]

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.

Comment 49

[drb24]

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

Comment 50

[Olav Seyfarth]

(from comment 49)
> I think you meant bug 219598 instead of 206199 (self-ref).

Yep, sorry.

Comment 51

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 52

[Asa Dotzler [:asa]]

adding [e-mail] who is listed at mozdev as the contact for
enigmail.

Comment 53

[Finlay McWalter]

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? ;(

Comment 54

[Patrick Brunschwig]

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.

Comment 55

[Matthieu Rotschi]

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

Comment 56

[Rainer Bielefeld]

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

Comment 57

[Lewis Rosenthal]

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
 

Comment 58

[Artur Polaczynski]

Attachment: gdb backtrace

Comment 59

[Artur Polaczynski]

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 

Comment 60

[Patrick Brunschwig]

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

Comment 61

[Artur Polaczynski]

>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 ;-( / ;-)

Comment 62

[Artur Polaczynski]

Attachment: better gdb stack trace (gcc -g2)

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;

Comment 63

[Patrick Brunschwig]

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 :-(

Comment 64

[Patrick Brunschwig]

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.

Comment 65

[Brendan Eich [:brendan]]

Patrick: thanks, I'm interested.  Look for me in irc.mozilla.org, brendan.

/be

Comment 66

[tammer]

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

Comment 67

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: assertion, valgrind warnings, and crash after installing enigmail and starting mail

Comment 68

[Brendan Eich [:brendan]]

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

Comment 69

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm a version behind.  See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsinterp.c&rev=3.134&mark=1488,4246

Comment 70

[Brendan Eich [:brendan]]

Ok, any idea where in SCRIPT_FIND_CATCH_START the UMR might be?

/be

Comment 71

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 72

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The first one was reading tn_->length, the second was reading tn->start (odd
that they were in different iterations, perhaps?).

Comment 73

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 74

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 75

[Brendan Eich [:brendan]]

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

Comment 76

[Brendan Eich [:brendan]]

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

Comment 77

[Brendan Eich [:brendan]]

Attachment: proposed fix

Essentially a one-line patch (diff -w version next).

/be

Comment 78

[Brendan Eich [:brendan]]

Attachment: diff -w version of proposed fix patch

Patrick, can you fix the const redeclaration in enigmail?

/be

Comment 79

[Brendan Eich [:brendan]]

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

Comment 80

[Brendan Eich [:brendan]]

Attachment: slightly better fix (no JS_UPTRDIFF dependency)

Comment 81

[Brendan Eich [:brendan]]

Attachment: diff -w version of latest proposed fix patch

Comment 82

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

attachment 138134 [details] [diff] [review] fixed the crash and valgrind warnings that I was seeing

Comment 83

[Patrick Brunschwig]

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

Comment 84

[Patrick Brunschwig]

For those using Enigmail, I have released Enigmail v0.82.6, which should not
have any const redeclarations anymore.

Comment 85

[timeless]

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.

Comment 86

[Mike Shaver (:shaver emeritus)]

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

Comment 87

[Brendan Eich [:brendan]]

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

Comment 88

[Brendan Eich [:brendan]]

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

Comment 89

[Asa Dotzler [:asa]]

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

Comment 90

[Brendan Eich [:brendan]]

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

Comment 91

[Stefan Mayrhofer]

has bug 226574 something to do with this issue?

Comment 92

[Micuel Zaugg]

Work around: After creating a new Profile Mozilla crashed anymore.

Comment 93

[Mike Kaply [:mkaply]]

Comment on attachment 138139 [details] [diff] [review]
slightly better fix (no JS_UPTRDIFF dependency)

a=mkaply

Comment 94

[Mike Kaply [:mkaply]]

Can someone put this on the 1.4 branch and mark it fixed1.4.2? or should I do it?

Comment 95

[Mike Kaply [:mkaply]]

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_++

Comment 96

[Mike Kaply [:mkaply]]

I took the new patch

Comment 97

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It doesn't matter, since nobody was using the result.

Comment 98

[Brendan Eich [:brendan]]

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

Comment 99

[Sven Krohlas]

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

Comment 100

[timeless]

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