Closed
Bug 223650
Opened 21 years ago
Closed 21 years ago
Using webmail to send an email causes Firebird to not respond and increase it's memory usage.
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: RickFriedman, Assigned: bugzilla)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031024 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031024 Firebird/0.7+
I have an email account with www.myfastmail.com. After logging on, I choose
"Compose" from the Fastmail menu. The compose screen comes up and I enter an
address in the "To:" field. Once I click out of the "To:" field, I can no longer
get any response from Firebird. Opening the Windows XP task manager shows
Firebird using 95% - 100% cpu usage. Also, the memory usage steadily climbs. It
got to 75MB before I killed the process.
Reproducible: Always
Steps to Reproduce:
1.Logon to www.myfastmail.com
2.Choose Compose
3.Enter address in "To:" field
4.Click out of "To:" field
Actual Results:
Firebird no longer responds. CPU usage reached 95% and memory usage for Firebird
climbs until the program is aborted.
Expected Results:
After clicking out of the "To:" field, Firebird should have simply moved the
cursor to the field I clicked into.
|
||
Comment 1•21 years ago
|
||
Please see http://forums.mozillazine.org/viewtopic.php?t=31354&highlight= for
other user's confirmation.
|
||
Comment 2•21 years ago
|
||
Happens in Windows 2000 SP4 as well, has never occurred prior to the 10/24/03 build.
Firebird was demonstrated to achieve a system footprint of 99% CPU utilization,
on an AMD Barton 2500, and over 150 MB of RAM. This took less than two minutes.
During that time, the program was completely unresponsive.
To replicate:
1. Log into any Fastmail (www.fastmail.fm) e-mail acc't.
2. Click on "compose" link.
3. Enter *ANY DATA* into the "to" box, then select another area of the screen.
Expected results: the browser should have merely moved focus to the selected
part of the page; EG., to the "Cc" field, "Subject" field, or main page for
scrolling purposes.
This will happen if you copy and paste a full e-mail address, or even enter in a
single character.
|
|
||
Comment 3•21 years ago
|
||
PS. This seems to ONLY happen in Fastmail's webmail interface, it does not
happen in Bellsouth's, and I have not heard of it happening in Yahoo or Hotmail,
which are far more popular and likely to have experienced issues if this was
broad in nature.
|
|
||
Comment 4•21 years ago
|
||
PPS. For anyone without a Fastmail acc't, source code for the "compose" window
can be found at the following address:
http://forums.mozillazine.org/viewtopic.php?t=31354
|
|
||
Comment 5•21 years ago
|
||
PPPS. Demonstrated to work in the 10/25/03 build as well.
|
Reporter | |
Comment 6•21 years ago
|
||
One of the developers of Fastmail has looked into the problem. He has tracked
down the problem to the RegExp matching code. It can be found at
http://forums.mozillazine.org/viewtopic.php?p=258639#258639.
In his message on the Mozillazine forum, he includes this test case:
<html><head><script><!--
function test() {
var s = "test";
var re = /((?:a|[^a])*)/g;
re.lastIndex = 0;
for (var i = 0; i < 2; i++) {
var matches = re.exec(s);
alert("matches=" + matches.join(":") + ", index=" + matches.index + ",
lastIndex=" + re.lastIndex);
}
}
--></script></head>
<body onload="test()"></body>
</html>
He says: "Clearly (?:a|[^a]) is really the same as anything, so ((?:a|[^a])*)
should match any string, however it fails to match in the latest nightly builds.
I tested this and it works correctly in older versions of Mozilla, IE and Opera.
FYI: The memory leak is because I've got a loop around a regexp like the one
above that should ALWAYS match one of it's sub-parts, but because it fails, it
goes into an infinite loop building up an array. So it's not a Mozilla memory
leak that's the problem, but a regexp problem."
Hopefully, this will help solve the problem.
|
||
Comment 7•21 years ago
|
||
A bug has also been filed against the JavaScript Engine on this:
bug 225289, "Regexp pattern /a|[^a]/ not matching correctly".
The fix for the regexp bug will be made in bug 225289. We could either
dupe this bug against that one, or add bug 225289 as a dependency here.
I'm in favor of the latter, so let me add the dependency now.
Once bug 225289 is fixed, everyone on this bug will get an email.
Then you can check if the fastmail.com site works properly again -
Depends on: 225289
|
|
||
Comment 8•21 years ago
|
||
OK, the fix for bug 225289 has been checked in today. So with
tomorrow's builds, the www.myfastmail.com site should work.
If anyone gets a chance, they can try this and report back -
|
|
Reporter | |
Comment 9•21 years ago
|
||
I have not seen an official nightly for Firebird since this fix went in.
However, I have been using Aebrahim's daily builds on 11/17 and today, 11/18.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031118
Firebird/0.7+ (aebrahim))
In both cases, the problem still exists with Fastmail. It still hangs in the
compose page, eating up CPU cycles & RAM.
|
|
||
Comment 10•21 years ago
|
||
Can anyone try the site with an up-to-date Mozilla build?
I'd be curious to see if Mozilla has problems as well -
|
|
Reporter | |
Comment 11•21 years ago
|
||
Phil,
I downloaded and installed today's nightly Mozilla build. I only installed the
browser component as that was all I was interested in.
Anyway, I went to www.myfastmail.com and opened the Compose page. Suffice to
say, the problem still exists in Mozilla as well. As soon as I left the "To:"
field, Mozilla refused to respond. Opening Task Manager showed it using 95% -
98% CPU and ever-increasing RAM usage.
|
|
||
Comment 12•21 years ago
|
||
Rick: what happens if you try this in the URL bar?
javascript: alert(/a|[^a]/.exec('a'));
If bug 225289 is acting up, this outputs nothing.
If bug 225289 is fixed, it should output 'a'.
|
|
Reporter | |
Comment 13•21 years ago
|
||
Phil,
I tried your javascript test:
javascript: alert(/a|[^a]/.exec('a'));
The output is an 'a'. So, I guess bug 225289 is fixed. However, the problem
still exists on www.myfastmail.com. There must be something else at work here.
|
|
||
Comment 14•21 years ago
|
||
cc'ing Rob to see what he thinks the problem might be.
Rob: I tried the test() function you posted at mozillazine
(Comment #6 ) in our JS shell after bug 225289 was fixed.
It seems to work fine now:
[d/JS_TRUNK/mozilla/js/src/WINNT5.0_DBG.OBJ] ./js
js> var alert = print;
js> function test() {
var s = "test";
var re = /((?:a|[^a])*)/g;
re.lastIndex = 0;
for (var i = 0; i < 2; i++) {
var matches = re.exec(s);
alert("matches=" + matches.join(":") + ", index=" + matches.index +
", lastIndex=" + re.lastIndex);
}
}
js> test();
matches=test:test, index=0, lastIndex=4
matches=:, index=4, lastIndex=4
This function no longer hangs in a loop, yet users at www.myfastmail.com
are still having problems -
|
|
||
Comment 15•21 years ago
|
||
This is Kai again - still happening for whatever nightly builds I've been able
to find on the Firebird homepage, and is occuring in both Linux(Slackware 9.1)
and Windows 2000.
|
|
||
Comment 16•21 years ago
|
||
I don't know how much code you folks shift daily on this program, but has anyone
considered using a program to compare the code from when the bug started
(10/24/03) to the code the day prior, or even the week prior, to determine what
precisely was changed? Sorta self-evident to try, but no idea if anyone's had
the time yet to do it.
|
||
Comment 17•21 years ago
|
||
Ok, I've looked into this, and I've found what's happening.
Basically it's a difference in how IE and old versions of Mozilla deal with
empty matches. Try this out:
<html><head><script><!--
function test() {
var s = "a";
var re = /(a)|([^a])/g;
re.lastIndex = 0;
var matches = re.exec(s);
for (var i = 0; i < matches.length; i++) {
if (matches[i] === undefined) { matches[i] = "str_undefined"; }
}
alert("matches=" + matches.join(":") + ", nMatches=" + matches.length);
}
--></script>
</head><body onload="test()"></body></html>
* Opera 7, Mozilla 1.6b
matches=a:a:str_undefined, nMatches=3
* Mozilla 1.5
matches=a:a, nMatches=2
* IE 6
matches=a:a:, nMatches=3
I think Opera 7 and Mozilla 1.6b are correct, but you can see there's
definitely some differences.
Moz 1.5 doesn't seem to fill all empty matches correctly
IE 6 seems to use an empty string ("") for empty matches instead of undefined.
Anyway, I've now updated my javascript to work in both cases, so it should now
be working with Moz 1.6b
For anyone who wants to test this out, login to your FastMail.FM account, go to
the compose screen and hit CTRL-F5 to force a reload of the javascript (there's
normally a 1 week cache time on the file)
Rob
|
|
Reporter | |
Comment 18•21 years ago
|
||
Rob,
That did it! The change you made to the javascriptsolved it. Once I entered the
compose screen, I refreshed (CTRL-F5), and found that once I clicked out of the
"To:" field, everything was as it should be. I was able to send off an email
with no problem.
Great work! Thanks!
|
||
Comment 19•21 years ago
|
||
wfm with aebrahim's 111703 build. looks like rob's "fix" worked.
the "empty match" issue should probably be openend as a new bug, though i admit
i'm not certain if this is a standards thing.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
|
|
||
Comment 20•21 years ago
|
||
Rob: nice catch!
ratman: your idea is correct: this is a standards issue: see bug 123437,
"regexp backreferences /(a)? etc./ must hold |undefined| if not used"
This was fixed with the recent rewrite of the Mozilla regexp engine
(bug 85721), and represents a change in behavior. Previous to this,
Mozilla did the same as IE.
You need to log in
before you can comment on or make changes to this bug.
Description
•