56934 - [IBENCH] Seamonkey cannot complete the Ziff Davis browser benchmarking test

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Chris Nalls]

I have just completed the i-Bench test suite, which is used by ZD publications 
to measure performance of web browsers. IE 5.5 ran the test fine. Today's build 
crashes when trying to run the test (at the Real test). And it has trouble with 
Java, Javascript, Flash and other plug ins.

Comment 1

[johng]

adding rtm keyword, cc'ing jar to get on pdt's radar

Comment 2

[sol]

Using Build 2000-10-16-08, I attempted to run the tests also, but was unable to
complete the tests.

I think we may be able to focus testing on the performance of the Netscape
client, and not on its interaction with Java and plug-ins.

However, even if we can accomplish the above, Seamonkey cannot run the basic
"Load Pages" and "Processing" tests included in i-Bench.

Steps to reproduce:
1. Install Seamonkey - I'm using build 2000-10-16-08, commercial, on WinNT4
2. Start Navigator and close My Sidebar (since My Sidebar processing should not
be included in the testing results)
2. Go to the beginning of the i-Bench tests at the URL:
    http://i-bench.zdnet.com/ibench/i-bench.htm
3. Choose the tests to run. I chose:
   Load Pages
   Processing
with a connection speed of:
   Intranet/LAN
4. Run the test

Expected result: You complete the Load Pages and Processing tests, and are
presented with a table that lists performance results.

Actual: The browser gets stuck on the following URL:
    http://i-bench.zdnet.com/ibench/performance_tests/loadspeed/benchmark.html
with the error:
    The operation timed out when attempting to contact i-bench.zdnet.com

Note: I ran the tests 2 times and got stuck on the identical page. I was able to
successfully complete this test using Communicator 4.72.

Comment 3

[Phil Peterson]

I played with this test a little, and Seamonkey stalls at pretty much the same
point every time, so I'm confirming the bug. I played with cache settings a
little, with no change.

I also tried it in winEmbed, which doesn't have all the Seamonkey chrome and
features, and it still stalls, but generates a Javascript exception (which I
don't see in the Seamonkey JS console):

JavaScript error:
 line 0: uncaught exception: [Exception... "Failure"  code: "-2147467259" nsresu
lt: "0x80004005 (NS_ERROR_FAILURE)"  location: "http://i-bench.zdnet.com/ibench/
testlist/tests.js Line: 595"]

As you noted, 4.7 screams through the test, so I do not believe this is a
legitimate server stall. I think it's a client-side problem, perhaps with layout
or networking. The JS exception seems worth exploring too.

Comment 4

[rickg]

For starters, I'm seeing the following assertions:

###!!! ASSERTION: NS_ENSURE_TRUE(prompter) failed: 'prompter', file 
s:\mozilla\dom\src\base\nsGlobalWindow.cpp, line 751
###!!! ASSERTION: nsStreamLoader not thread-safe: 'owningThread == NS_CurrentThr
ead()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: HTMLContentSink not thread-safe: 'owningThread == NS_CurrentTh
read()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: nsHTMLHeadElement not thread-safe: 'owningThread == NS_Current
Thread()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: nsHTMLBodyElement not thread-safe: 'owningThread == NS_Current
Thread()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: nsHTMLHtmlElement not thread-safe: 'owningThread == NS_Current
Thread()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: nsDocument not thread-safe: 'owningThread == NS_CurrentThread(
)', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: nsDocument not thread-safe: 'owningThread == NS_CurrentThread(
)', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: CSSLoaderImpl not thread-safe: 'owningThread == NS_CurrentThre
ad()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490
###!!! ASSERTION: nsHTMLHtmlElement not thread-safe: 'owningThread == NS_Current
Thread()', file s:\mozilla\xpcom\base\nsDebug.cpp, line 490

Comment 5

[rickg]

Sol, Phil, et al (whoever he is): The problem is that the <body
background="foo"> is either invalid or didn't load, so OnLoad() is never called
on this page, which means it won't go to the next page. It seems that IE and nav
call onLoad() before all the images are loaded.

I'll reassign this to pam nunn for further review.

Here's the min testcase:

<html>
  <body background="bg-labs.gif" onLoad="document.location='benchmark1.html'">
    I get stuck!...
  </body>
</html>

Comment 6

[pnunn]

I'll take a look.
-pn

Comment 7

[lchiang]

Looks like we need this for rtm (from Marketing perspective).  Pam, can you or
your manager mark this bug [rtm need info] so that we get this on the radar as a
possible bug we need addressed for rtm.  Thanks.

Comment 8

[ekrock's old account (dead)]

Marking [IBENCH] to ease searching.

Comment 9

[selmer (gone)]

Yikes!  We really really want this ASAP for the RTM branch!!!  What can we do to 
get this fixed right away?

Comment 10

[pnunn]

clone me?
-pn

Comment 11

[pnunn]

Rick,
thanks for isolating the problem. 
-p

If I can find the image, I can display it. It looks like
something is wrong with how we resolve the url, or the
way we make the request.

-p

Comment 12

[pnunn]

The real location of the image in question is:
http://i-bench.zdnet.com/ibench/performance_tests/loadspeed/gifs/bg-labs.gif

but the request sent to the imglib is:
 "http://i-bench.zdnet.com/ibench/performance_tests/loadspeed/bg-labs.gif"

-pn

Comment 13

[Jason Eager]

Hmm..another OnLoad() problem, eh?

Take a look at bug 51013. This isn't the first time we've had OnLoad problems.

Comment 14

[pnunn]

updating url to problem page.
-p

Comment 15

[pnunn]

Gagan:
Who handles url resolution issues?
If there is no one to do it, I'll be happy
to dig into it.

Reassigning to you.

-P

Comment 16

[pnunn]

I just checked to be sure we an ImageConsumer::OnStopRequest()
for the bad image url. We do. We also get an ImageNetContextImpl::RequestDone().

What kicks off the onload() js condition?
-pn

Comment 17

[Gagan]

Pam: both the URLs you mention do return the same image. I believe their server
is configured to send the same image in either case. So url resolution is not
it! I would strongly suggest getting input from someone on docshell/dom team to
figure out what's preventing the onLoad call. 

Comment 18

[Jim Roskind]

Hmm... based on that last comment... it doesn't sound like we're getting great
traction on this... and this is listed as a Very Important (TM) bug on the
marketing radar  I've cc'ed some additional heavy hitters in hopes that they'll
feel the urge to nail a bug... and jump in.

Any volunteers??

Comment 19

[rpotts (gone)]

The OnLoad() will fired when the loadgroup for the document is empty.

It sounds like either a channel is sitting in the loadgroup - and thus causing 
the group to be busy.  Or, when the final channel is finished and the "Document 
Done" notifications are fired, the result code is a FAILURE. This would also 
prevent the OnLoad from being called...

-- rick

Comment 20

[Scott MacGregor]

I'll try to take a look at this tonight. 

Comment 21

[Scott MacGregor]

Your right on the money rpotts. The image url is the last url we run for the
document and it generates an error because we can't find the image. That error
is propogated up in the OnStopRequest the file channel sends the docloader.
Since it's the last running url, the doc loader propogates this same error code
as the resulting error code for the document load when it fires a
OnEndDocumentLoad. So we end up failing to fire the on load notification.

The "easy" fix would be to ignore load errors for images when propogating up the
OnStopRequest chain. However, all we have is a file channel on the bottom of the
stack, we don't know it was supposed to be from an image so there's no clear way
to filter based on that criteria.

Still thinking....

Comment 22

[Gagan]

Hmmm... I was also investigating this though from a slightly different angle. I
found that the count of the channels drops to -1 becuz we are trying to remove
the bad channel (bad image pointing to an HTML link) thru a Cancel call. Not
sure if this results in the loadgroups not calling OnStop. 

Seems like mscott you are already investigating that... so go forth! :)

Comment 23

[Scott MacGregor]

Attachment: the fix

Comment 24

[Scott MacGregor]

I just attached the fix for this bug. benchmark.html has a image tag that looks
like:
<IMG SRC="home.html">

Of course home.html is actually html content and not an image.

image lib would ask http to open a channel for home.html which http dutifully
did. We then started showing image lib the content for this url by calling
OnDataAvailable. Image lib, decides it really doesn't like to display text/html
content so it returns NS_ERROR_ABORT from OnDataAvailable.

Now http doesn't realize image lib no longer cares about this request. Image lib
is no longer reading data out from the pipe. Eventually http blocks trying to
write more data into the pipe because the pipe is full.

this http channel never propogates an OnStopRequest because it's blocked waiting
to write the rest of the content into the pipe for image lib. But image lib
isn't reading data anymore. Because the OnStopRequest is never issued, this
channel stays in the load group for the document. As such, the load group is
never empty of channels. Which in turn means that we never fire the on load
handler for the document because we never think we are done. And because the on
load handler never fires, we never try to load the next URL in the benchmark tests.

all because of an image tag whose src was really text/html.

the fix is pretty straightforward, if the consumer of the http channel returns
NS_ERROR_ABORT in response to an OnDataAvailable call, then go ahead and cancel
the channel.

Instead of modifying http to do this, we could also expicilty cancel the channel
in image lib's OnDataAvailable call. In fact, that may be preferred.

In either case, the channel needs to be canceled in this scenario and all
becomes well again.

I'm happily zipping through the benchmark test right now on my WinNT box.

Can I get a r=sr= from some folks? I'd like to check this into the tip tonight
so others can verify in tip builds tomorrow morning. 

Comment 25

[lchiang]

Please, someone r and sr soon :-)  We are waiting on this bug to make some press
CDs. Thank you.

Comment 26

[Scott MacGregor]

Attachment: another way to fix the problem in image lib...

Comment 27

[Scott MacGregor]

I just attached another patch which I think I like better. They both fix the
problem but the second involves changing image lib instead of the http channel.
Whenever ImageConsumer::OnDataAvailable would have returned NS_ERROR_ABORT,
signaling the fact that they want to cancel this request, I changed to actually
Cancel the channel itself.

This makes a bit more sense then having a random check after http calls
OnDataAvailable for NS_ERROR_ABORT. Especially since none of the other protocols
are checking for this error value. It's inconsistent that http would.

Comment 28

[Gagan]

I like the second patch r=gagan.

Comment 29

[rpotts (gone)]

hey scott,
this sounds like a reasonable patch.  In fact I think that this is really the 
technique that we want to use when cancelling a channel from a stream listener 
notification.

Although I'm a little confused why the channel was not being canceled already... 
Warren and I added some code in nsAsyncStreamListener.cpp to cancel the channel 
if one of the PLEvent callbacks failed...  Any idea why this code is not kicking 
in?

Comment 30

[rpotts (gone)]

sr=rpotts.

But I'm still interested why the code in nsAsyncStreamListener did not cancel 
the channel...

-- rick

Comment 31

[Scott MacGregor]

Hey Rick, I can answer that question for you. It's because the
nsAsyncStreamListener never sees this error value. the http response listener
does not properly propogate the error from on data available back down to the
nsAsyncStreamListener::OnDataAvailable.

Here's the http response listener code snippet:

        rv = mResponseDataListener->OnDataAvailable(mChannel,
mChannel->mResponseContext, i_pStream, 0, i_Length) ;
        // THE rv we got here is the NS_ERROR_ABORT that imagelib gave us..

        // Report progress
        rv = mChannel->ReportProgress(mBodyBytesReceived, cl) ;
        if (NS_FAILED(rv)) return rv;

oops, we just stomped on the return value in order to report progress.

Comment 32

[Scott MacGregor]

in fact, just properly propogating that error code back out of the http response
listener does in deed fix the problem too. The fix is much simpler as well:

Index: nsHTTPResponseListener.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp,v
retrieving revision 1.129
diff -u -r1.129 nsHTTPResponseListener.cpp
--- nsHTTPResponseListener.cpp  2000/09/05 21:22:33     1.129
+++ nsHTTPResponseListener.cpp  2000/10/24 20:39:52
@@ -552,6 +552,7 @@
         }

         rv = mResponseDataListener->OnDataAvailable(mChannel,
mChannel->mResponseContext, i_pStream, 0, i_Length) ;
+        if (NS_FAILED(rv)) return rv;

         PRInt32 cl = -1;
         mResponse->GetContentLength(&cl) ;

If the consumer returns an error from OnDataAvailable, then return that error
code. This causes the underlying nsAsyncStreamListener to cancel the chanel for us.

No need for changing the image lib code.

Rick, what's your preference for fixing this bug? I think I'm in favor of
properly passing the error condition down to the async stream listener code and
letting it perform the cancel.

Comment 33

[rpotts (gone)]

I think that properly passing the return code throught the HTTP response 
listener is the right thing to do too!!

It will also catch any other places where a consumer expects this behavior :-) 
[Right now I think imagelib is the only one - but hey, who knows :-)]

(a,r,sr)=rpotts - Take your pick... whichever you need :-)
-- rick

Comment 34

[Jason Eager]

lchang: If you make press cd's without bug 56349 being fixed (different bug from
this), we're going to get nailed AGAIN by the Byte reviewer, and many other
reviewers, for having NO bookmark management facilities working.

Comment 35

[Scott MacGregor]

Attachment: the final one line fix rpotts and I are happy with

Comment 36

[Scott MacGregor]

gagan, can you gimme that one last r= on this one line patch to propogate the
error code? I'll get it on the radar for the 4pm PDT meeting today if you can. 

Comment 37

[Gagan]

r=gagan

Comment 38

[Jason Eager]

This has a r=, and sr=, and should go to rtm+ asap.

Comment 39

[Scott MacGregor]

I could have sworn I changed this to rtm+ after gagan reviewed it. No wonder PDt
hasn't looked at yet. And here I am spinning my wheels =).

I've checked this into the tip. Waiting for the double plus to land on the branch. 

Comment 40

[Michael La Guardia]

Marking ++ per Lisa Chiang's comments below and a conversation with Phil.  Lisa
writes in email:

"This is the bug that Marketing wants fixed.  I'd say let's try to ++ this
before tomorrow so that this can make it into the 10-25 am builds.  Scott says
in the bug that he's run through the ZD tests without any problem with the
patch.   I can't read the patch like phil, jar, and selmer can :-) so I don't
know if the patch is complicated or not.  I know that Marketing wants this in
any candidate build.

Lisa"

Comment 41

[Scott MacGregor]

Fix checked into branch and tip. Enjoy!

Comment 42

[sol]

I'm running today's build (2000-10-25-09-MN6, commercial) on WinNT4, and I
*cannot* complete the i-Bench test.

I get stuck on the following URL:

    http://i-bench.zdnet.com/ibench/performance_tests/loadspeed/sidebar1.html

As I mentioned above, I'm running the "Load Pages" and "Processing" tests with
an internet connection speed of "Intranet/LAN".

I believe I made it about 3 pages further than the last time I tried to run the
test.

Am I using a build that contains the fix?

Comment 43

[sol]

OK - I've got gremlins in my machine.

Using a brand new profile, I am still failing in about the same part of the test.

Details:
1. I created a new profile.
2. I checked the cache preferences - my disk cache is set at 7680 Kb with the
preference to check for new pages "Once per session". (Note that in the tests
above, my disk cache was 5,000 Kb with the preference set to "Every time I view
the page".)
3. I started the test - "Load Pages" & "Processing" at the speed "Intranet/LAN".

Expected result: Make it through the test.
Actual result: I stopped twice on the same URL
    http://i-bench.zdnet.com/ibench/performance_tests/loadspeed/sidebar2.html

I saw that many other people were able to make it through the test successfully.
As long as these testers were using the same bits that we are sending out the
door (i.e., not debug builds), then I will treat my results as an aberration.

If others could confirm their success in this bug, I'd feel a lot better.

Comment 44

[Scott MacGregor]

There's definetly another problem here. But entropy and timing is involved.
Turns out there were two problems in this bug. The first one which I fixed and
another one.

The last element in sidebar1.html is an image tag which refers to a bogus image.
We receive a 404 from the server when we try to fetch this image. This 404,
eventually gets translated into an error for this request. Here's where the
entropy part comes in. If due to bad karma, this is the last url we finish
fetching then the error code generated in this OnStopRequest is the one used
when we call OnEndDocumentLoad. So OnEndDocumentLoad sees an error and fails to
fire the on load handler.

If another request happens to take a little longer (which happens most of the
time), then it succeeds so the error code passed to OnEndDocumentLoad is a
success code and the on load handler is fired.

Re-opening until we can resolve this issue which seems pretty serios. 

Comment 45

[Scott MacGregor]

Attachment: potential hack to work around race condition with sidebar1.html

Comment 46

[Scott MacGregor]

Here's a potential hack we could use for the marketing CDs until we can think of
a better solution. Basically, if the http channel is about to propogate up an
error code when it calls OnStopRequest, I put a hack to check for a 404 status
code. If we encountered a 404, then reset the error code to NS_OK.

With this change, I've been able to run the zdnet test 3 times in a row without
stalling on windows. I'm about to test linux and windows now.

I'm not pretending this isn't a total hack. It is. But I don't have anything
better yet. Still poking....

Comment 47

[Scott MacGregor]

Okay, here's the problem. As I said before, currently when the last request for
a document is finished, we fire OnEndDocumentLoad using the status code
associated with that last request. I believe this is incorrect. As it leads to
problems like we are seeing here where the last request is sometimes an image
that doesn't exist so we consider the entire document load a failure.

I'm going to assert that the following should be the correct policy for
determining the status of a document load:

1) If the entire load group is currently being canceled, then we definetly want
to propogate the error code up to the end document load.
2) Get the status on the main document channel and use that status result as the
status for the OnEndDocumentLoad. Don't use the status code for the last request
we happen to finish as the status for the load.

rpotts just independently came up with the same approach so I feel pretty good
that's it the right thing to do.

I'm about to attach a patch that implements this policy. So far the benchmark is
running multiple runs without stalling with this patch.

Comment 48

[Scott MacGregor]

Attachment: fix for correct error propogation into on end document load

Comment 49

[Scott MacGregor]

sr=rpotts, r=sspitzer on this docloader/load group change. Moving to rtm+.

(I'm still testing this on linux as I write this.....windows checks out)

Comment 50

[Phil Peterson]

Talked this over with mscott and between the testing done so far and the need to
get this fixed yesterday, I'm marking rtm++.

Comment 51

[Phil Peterson]

Scott found a problem with the patch. Back to rtm need info.

Comment 52

[Scott MacGregor]

I was going to check this into the branch tonight but I found a small problem
that makes me think I should wait for some others to test on the tip before
checking in.

Gagan, I noticed that the http channel doesn't update mStatus based on the
status code it gets in ::ResponseCompleted. I'm now relying on getting the right
status code from the channel in certain cases instead of relying on what status
code gets passed in for the OnStopRequest.

I needed to make the following change to nsHTTPChannel::ResponseCompleted to set
mStatus based on the status argument passed in here.

Index: nsHTTPChannel.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp,v
retrieving revision 1.234.2.7
diff -u -r1.234.2.7 nsHTTPChannel.cpp
--- nsHTTPChannel.cpp   2000/10/25 18:10:23     1.234.2.7
+++ nsHTTPChannel.cpp   2000/10/26 07:26:45
@@ -1919,6 +1919,7 @@
     //----------------------------------------------------------------
     if (aListener)
     {
+        mStatus = aStatus; // set the channel's status based on the respone status
         rv = aListener->OnStopRequest(this, mResponseContext, aStatus,
aStatusArg);

There may be more places were this doesn't get set. I'll do an audit.

Not having this status variable properly set does NOT effect the fact that the
patch as stands fixes the remaining problems we had with ZDNET.

But the patch introduces some smaller regressions. For instance, it is now
possible to type in a bogus server in the url bar and you'll no longer get a
dialog saying we were unable to connect to the server you typed in. This one
line fix catches that problem. But the risk factor for this patch is other
problems "like that on". If that makes sense.

Comment 53

[Gagan]

Seems ok to me... but wouldn't you want to update mStatus in all cases of
ResponseCompleted (and not just if you have a Listener)? In order words, move
the mStatus = aStatus line outside and before the if check. Maybe even right
when we enter ResponseCompleted. 

Comment 54

[Scott MacGregor]

I just thought of a really good way to reduce the risk of this change on the
BRANCH only.

Rick, what do you thinking about wrapping my new call from the doc loader to get
the load group status with a check to ONLY perform it if the error condition is
NS_BINDING_ABORTED. This check would go into the branch only as it isn't
correct. But for the case of ZBENCH, the errors we are running into all come
from canceled requests (images that don't exist, an image tag that points to
html, etc).

With such a check, we would only change the current behavior and stomp on the
return code under a very specific condition where the error code is
NS_BINDING_ABORTED. In the cancel case, the status on the channel is always set
correctly.

With such a change, we don't open ourselves up to problems like I just saw late
last night where in certain cases the http channel wasn't updating the status of
the channel correctly for certain errrors. We can flush out and make sure the
other protocols are behaving correctly in this regard on the tip without hurting
zdnet or the branch.

What do you think?

Comment 55

[Scott MacGregor]

After talking to Michaell, I just checked this patch into the branch so
marketing can get a CD with this fix on it. We can consider backing it out again
once the CD is made if we feel we need to do more risk analysis before landing
it for good.

Comment 56

[rpotts (gone)]

hey scott,
that seems like a reasonable strategy for the branch (only).  That way we can 
iron out any regressions that it introduces on the trunk...

Comment 57

[Scott MacGregor]

Attachment: proposed doc loader change for the BRANCH only to minimize risk

Comment 58

[Scott MacGregor]

I like that idea too =). I just attached a patch to nsDocLoader which is
intended for the branch to minimize the risk of the checkin. The nsLoadGroup
changes from before still apply.

if aStatus == NS_BINDING_ABORTED or NS_ERROR_ABORT then invoke the new load
group code. Otherwise keep the same status code we used to pass on.

This minimizes when we'd be calling the new code.

rick, can I get a final sr from you for this doc loader change?

Comment 59

[rpotts (gone)]

hey scott,
I think the patch looks ok...  You might want to change the explicit test for 
NS_BINDING_ABORTED to just 'if (NS_FAILED(aStatus))' since this will also deal 
with any other errors that the last channel could encounter - such as 
DNS/connection failure, timeout, etc...

sr=rpotts

Comment 60

[Scott MacGregor]

Hey Rick, but that would defeat the point of limiting the scope of this change
for the branch =). I wanted to make it so we only use the "correct" status code
if the current status code is a binding aborted condition. The idea was to only
bother throwing away the current status code in place of the load group status
for the entire load IFF it was a cancel case. This is because not all channels
(like the http example I ran into) are properly setting the status on the
channel to match the status they pass out in the OnStopRequest call.

Comment 61

[rpotts (gone)]

ok...  you're right.  I'm just being stupid (again) :-)

Comment 62

[Scott MacGregor]

Moving back to rtm+ state. PDT, I'd like to checkin this last patch for the
BRANCH only per the discussion above. This minimizes the risk for the change.

Here's what would get checked in:
1) nsLoadGroup.h/.cpp changes were checked in this afternoon so marketing could
get their CD. Those changes would stay in the branch.
2) nsDocLoader.cpp patch to only invoke the new code if we received a canceled
status for the last request processed in loading a document. This won't be
checked into the tip.
3) Back out the one line nsHTTPChannel.cpp change checked in this afternoon for
marketing. With (2), this change is no longer needed. This change will remain on
the tip though as it needs to be there.

I hope that makes some amount of sense.

Comment 63

[selmer (gone)]

rtm++

Comment 64

[Scott MacGregor]

the right set of changes are in the branch and the right set is now in the tip
too. Marking fixed.

Comment 65

[Doron Rosenberg (IBM)]

2000102704 win98 mozilla trunk, started the test - "Load Pages" & "Processing"
and passed it.

before I mark this verified: chrisn and sol, is it passing for you as well?

Comment 66

[lchiang]

chrisn and sol are out.

We tested the patch for branch that mscott comments on 2000-10-26 12:48 and that
passed on Linux, Mac, and Win32 on several machines, under several iterations of
the test.

Still need to test branch with mscott's final fix (proposed 10/26/00 14:23 patch).

I can assign this bug to myself if you want, doron.

Comment 67

[lchiang]

Sol and others ran using a build immediately after this last patch was made and
were successful.

As an additional test, I'm running several (2-3) reiterations of the test at the
above URL on branch builds:
win32:  2000-11-04-09
linux:  2000-11-04-09
mac:    2000-11-04-08

mark verified since doron verified on trunk as well.