Closed
Bug 81480
Opened 24 years ago
Closed 24 years ago
Results page not being posted to client after ibench run
Categories
(SeaMonkey :: General, defect, P2)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
mozilla0.9.4
People
(Reporter: pawyskoczka, Assigned: gagan)
References
()
Details
(Keywords: hang, Whiteboard: [ibench] mac only)
Build is 2001051608 on Mac
Steps:
1. Launch browser
2. Start ibench test
3. Ibench test completed and page displays "Completed loop 8 of 8"
4. Throbber is running, running, running
5. I waited for about 30 minutes and the page finally loaded as
<html><body></body></html>
Notes:
This is preventing ibench testing on Mac
The linux is fixed in this release, so it's not related to that problem
Mac platform now...
Gagan, who on your team can we get some help from??
Hardware: PC → Macintosh
Comment 3•24 years ago
|
||
mass setting milestone. if this is something you believe is more urgent then
the milestone that I just sent, please send me mail.
Target Milestone: --- → mozilla0.9.3
Comment 4•24 years ago
|
||
Subject:
Bug 81480 - Results page not being posted to client after ibench run
Date:
Fri, 18 May 2001 08:28:08 -0700
From:
paw@netscape.com (Paul Wyskoczka)
To:
Doug Turner <dougt@netscape.com>, Cathleen Wang <cathleen@netscape.com>,
Chris Hofmann <chofmann@netscape.com>
Doug, I think this needs to be fixed for beta. This test will be run by
reviewers and if it doesn't return data. That will not be cool.
Paul
Keywords: nsbeta1
Target Milestone: mozilla0.9.3 → mozilla0.9.1
Comment 6•24 years ago
|
||
Paul, when did this stop working? Did it ever work? Are there other known
posting bugs?
it stopped working on 5/15 build, but hey, I just looked at Paul's test results
page, looks like he is getting results from Friday 5/18 build.
paw, did you get the results from browser or from database?
Seems like this is working again. Closing as such...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
not quite yet... :-)
I talked to paw, and he said that he was able to get ibench test result by using
a brand new profile, but it works only on 1st run. On subsequent runs, even
with a clean profile, he is unable to get Mac ibench results...
The interesting thing is... why does a clean profile matter? and how come it
only works on very first run? What's broken? Most people are not going to
delete their existing profile and re-setup just to run ibench test...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 10•24 years ago
|
||
Cathleen is correct. It was working until 5/15. This morning I created a new
profile and was able to get the results displayed. When I reran the test using
the the same profile the results were not displayed. The browser was waiting
for server as described above.
Comment 11•24 years ago
|
||
hey paw, can you do us a favor?
when you run the test tomorrow morning (or next time)... can you see if you can
delete cache and/or cookie and/or histry to see if any of those will help
getting ibench to run. hope to find some ideas as to what's blocking the
ibench result page from showing.
big thaaanks!!
Reporter | ||
Comment 12•24 years ago
|
||
I always delete the cache before running the test. But I will try the other
items that you mentioned.
Comment 14•24 years ago
|
||
is this working now?
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 15•24 years ago
|
||
Unknown. I can't even get through an ibench run (it throws PDF and other crap at
me, which puts up download dialogs).
Comment 16•24 years ago
|
||
simon: try running just the html page load tests.
Reporter | ||
Comment 17•24 years ago
|
||
It still seems to be happening. One thing I noticed was that on the first run
after creating a new user, ibench throws up a dialog warning that the results
will go to the server. Most of the time I uncheck the checkbox so it won't
display the dialog on subsequent runs. On the Mac I stopped doing it and now
the run completes and displays the results. Same goes for Windows on today's run.
Comment 18•24 years ago
|
||
gagan, any updates on this?
have we figured out what's causing result page not get posted?
Assignee | ||
Comment 19•24 years ago
|
||
no updates. Anyone is welcome to take this bug from me if they want...
Comment 20•24 years ago
|
||
gagan, this bug is creeping back again... on Friday's build. :-)
see http://slip/projects/mojo/perf/i-bench.html
Assignee | ||
Comment 21•24 years ago
|
||
So here is what I find. After the pages are all done I get a modal dialog for
a security warning. This dialog hides behind the main window cuz the main window
still continues with a refresh. This may be the "perceived" hang. I had to
pretty much kill the app and restart the test. However this time I resized it so
that I could click on the security dialog box. On doing so, everything worked
just as expected. I could get to the results.
I guess the only way to work around it would be to have a preference added to
the prefs.js that disables that security dialog box from appearing. Here is the
relevant line for that--
user_pref("security.warn_submit_insecure", false);
I don't think there can be a way to make that be false automatically on a new
profile. So you'd have to make sure you do this manually before you run the
ibench tests.
So marking WORKSFORME with this workaround. Wish we had a better solution... :-(
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 22•24 years ago
|
||
that's an awful workaround.
Status: RESOLVED → REOPENED
Keywords: hang
Resolution: WORKSFORME → ---
Summary: Results page not being posted to client after ibench run → modal security warning dialog hides behind the refreshing main window
Whiteboard: [ibench]
Comment 23•24 years ago
|
||
"This dialog hides behind the main window cuz the main window
still continues with a refresh"
Isn't that the real bug? Is there a bug filed on it? Maybe it's a dup of the bug
about window's getting focused on page load?
Comment 24•24 years ago
|
||
Let's not morph this bug.
What I saw on Friday does not jibe with having that modal dialog coming up
and being hidden behind the main window. That would have meant that I would
have not been able to otherwise interact with the main window, but I could
do that. [I was going to confirm my experience at some point, but this
morphing forced my hand before I could do that in detail].
Bug is still open since I don't think the form submission is failing due to
the modal dialog.
If the other condition does in fact occur, then file a separate bug.
Summary: modal security warning dialog hides behind the refreshing main window → Results page not being posted to client after ibench run
Assignee | ||
Comment 25•24 years ago
|
||
I agree its an awful workaround *shrug* and I have filed a separate bug for the
same -- bug 84047.
I also agree with jrgm that we should not morph this bug. John if you can
provide some more info on when and how you are seeing this (inspite of the
security dialog box workaround) then I can try investigating it more, otherwise
this just works for me (modulo bug 84047)
Comment 26•24 years ago
|
||
I'll look into this this evening, and hopefully set up a testcase where
you don't need to run the full test just to get the final submission (where
it stalls).
Comment 27•24 years ago
|
||
I'm sorry (I think). Maybe it was the case that I couldn't interact with the
page, which would be consistent with the situation where the 'form submission'
alert winds up behind the parent window.
I have the same logic in a continuous loop, and so far, with the pref set as
|user_pref("security.warn_submit_insecure", false);| it has done 15 form
submissions in a row without hanging.
However, that same test, with |user_pref("security.warn_submit_insecure",
true);| wound up hung 2 of 3 times I tried (alert behind parent window).
So, I'll close this bug as WFM, and reopen if I get hung doing the full test
and the pref is set to false (don't come up). That makes bug 84047 the bug
for the hung dialog case (pref set true).
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 28•24 years ago
|
||
Okay, I'm not on crack. When it "hung" on Friday, I wasn't in the state with
the modal dialog somehow behind the parent window. And just now, I got into
the same "hang".
The state I am in is this:
1) the submit pref is false; so no dialog will come up, and POST submissions
should not be blocked from being transmitted.
2) the POST (done via a JS .submit()) is received at the server. (It's in the
server logs).
3) the browser is, however, dropping the response document on the floor. It
is just sitting there spinning: the throbber is animated. The current
document, as far as browser reload is concerned, is the document that
did the POST form submission.
4) I can grab the browser and move it around. I can open a new window. I can
'Stop' the current transaction. (The browser is not hung; it's just spinning
necko threads forever waiting for something).
5) Unfortunately, even though I can hit 'Reload' successfully, the JS logic
will invalidate the previous result, and I can get no information back from
the server about the test run.
6) I can see from the server logs of Linux and Win98 that the next thing the
browser is supposed to do, after getting the response document to the first
POST, is to do another POST. Now, the server never hears about that second
POST, but I don't think the browser has even "heard" the response to the
first POST (i.e., it has botched the response handling to the first POST).
All I can suggest is to either turn on logging for Necko and see what turns up,
or just run a debug Mac build against this full test until you hit this
condition in a debuggable build (first disabling the submit pref, which is
an independent bug from this one).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 29•24 years ago
|
||
john: does this happen with your shorter test cases? or we have to run the whole
suite? Is there a way we may tweak the ibench tests to run only once instead of
the default 8?
Comment 30•24 years ago
|
||
It doesn't happen with my shorter test case since I probably skipped something
about the complete finishing sequence (maybe something about the nature of the
document and/or headers returned in the response to the first POST).
It would be pretty easy to modify the ibench test to run a shorter series, at
least for debugging purposes for this bug. All that needs to be done is to
find the file 'finis3.html', which IIRC is in the performance_tests directory
for the ibench content. There is a line near the top: 'var maxLoops = 8;'.
Set the 8 to 2, and you have the shorter test. (You can't set it to '1' or
other stuff will barf, and you won't be tracing the normal test completion
sequence).
Comment 31•24 years ago
|
||
the fact that this bug is not easily reproducible hints to some sort of socket/
http-connection race condition. given that, it would be a great idea to try to
get a http log and also a socket log if possible. (i wonder if excessive logging
or even a non-optimized build would mask this bug.)
Comment 32•24 years ago
|
||
Might also want to run with Intararchy's traffic watching feature turned on.
Comment 33•24 years ago
|
||
This bug struck again today. It wound up in this 'spinning forever' mode, and
would not display the final results.
Perhaps benc or bbaetz can lend some time and we can do some logging of the
traffic and see what goes wrong.
QA Contact: doronr → benc
Comment 34•24 years ago
|
||
I've been hitting several page-won't-finish-loading bugs (bug 77072, bug 85025,
85357)
I think that something to do with http connection management has problems.
Narrowing those bugs down is a high priority for me, but I'm not sure that all
of them are related. I'll look into this as well.
However, even the minor overhead of packet sniffing seems to hide most of these
bugs (with the exception of 85357) logging, even on an opt build, is usually out
of the question.
FWIW, I was running ibench last week without problems on an opt build with no
logging.
I play with it when I get in today.
Comment 35•24 years ago
|
||
Do we need to be getting a tracer on a separate system between the client and
sever, or is there some other problem?
Comment 36•24 years ago
|
||
Failed again tonight.
The last thing that happens is that the browser executes a POST with a
javascript .submit() on a hidden form, which is received by the server
and logged. But the browser is dropping the returned document (which is
also supposed to do a POST on a hidden form to fully complete the test
and display the results).
I think we need the logging more than the packet info.
I may also have a simpler test, derived from the ibench stuff, setup in a while
(which is actually breaking all three platforms, although not quite with the
same "hanging").
Comment 37•24 years ago
|
||
I ran with this today on the zdnet server, and it worked for me.
I just reran now (on dogspit) and it WFM again
I wasn't trying to do timing, so I was doing other stuff while the tests were
running, but I can't see a problem.
Comment 38•24 years ago
|
||
As bbaetz and I discussed, he wasn't running on Mac, and this is a Mac-only
bug.
Whiteboard: [ibench] → [ibench] mac only
Comment 39•24 years ago
|
||
Note that the fix in bug 85514 might help this.
Comment 40•24 years ago
|
||
cathleen sent out a yell for help for this one so I tried this with my Powerbook
G3 running MacOS 9.04, buildID 20010620 and (un)fortunately, it WFM.
More particulars:
I ran the tests via a dialup connection. I tried this with my months-old
profile. Before running the test (all from dogspit), I cleared my mem and disk
cache via prefs dialog. Ran test three times and each time it came back with
the test results.
I did notice that as the test was running, the whole machine was very
unresponsive, as if a 'top' command would show the process using close to 99.99%
CPU. This is true for when the test was pulling pages from the server as well
as from local cache.
Comment 41•24 years ago
|
||
So I was able to reproduce this problem on my Mac with an opt build. Gagan and I
looked at it, broke into the debugger, and did an |sc6|. We were hung in the
modal dialog loop, presumably waiting for the security dialog.
John, next time your mac hangs, could you hit the Open-Apple-Power key combo
(flower power!) to break into MacsBug? (I'm assuming you've got macsbug
installed...) Once there, type
log stack.txt
sc6
es
(That will open ``stack.txt'' for output, do a stack crawl, and then return to
the shell.)
Comment 42•24 years ago
|
||
The modal dialog loop shows up because sometimes we put up a modal dialog behind
one of the browser windows (or the iBench scripts focus the browser window,
bringing it in front of a dialog, or something).
jrgm said above:
"Okay, I'm not on crack. When it "hung" on Friday, I wasn't in the state with
the modal dialog somehow behind the parent window. And just now, I got into
the same "hang".
so maybe there is > 1 issue here.
Assignee | ||
Comment 43•24 years ago
|
||
simon that is a possibility and that is the only reason why I haven't closed
this bug. but I really haven't been able to get to that latter stage ever. I'd
hate to close this bug without getting jrgm happy about this. If there is indeed
another problem than the bug 84047 then we need to find that and so far I
couldn't.
Comment 44•24 years ago
|
||
Yes, it is possible to wind up with the modal dialog behind the browser window.
But, no, that is not the "hang" that I regularly see. The browser is not
locked up, but the throbber is spinning forever and the final page is not
displayed.
I hit this several times on the weekend when running this test with two
different 450MHz/G4 Mac's, so it is not unique to that ~260MHz test machine.
I will run this test on the G4 in my cube, and will get the stack trace when
I hit this state (although since the main UI thread is idle, I may need some
additional info on how to get the necko thread info).
Comment 45•24 years ago
|
||
By the way, there is a third 'finish' that happens with the test on the Mac,
other than 'success' or 'hang/spin'. Sometimes it blats the final results to
the screen as plain text of the HTML source (i.e., <td>Result</td><td>123</td>)
Perhaps that is a hint.
Comment 46•24 years ago
|
||
using N6.1B1 I can reproduce the problem with the following stack trace
Calling chain using A6/R1 links
Back chain ISA Caller
00000000 PPC 3D8C9654
165269F0 PPC 3D8B9AA0
16526990 PPC 3D8B914C
165266B0 PPC 3D6900DC NSGetModule+0180C
16526670 PPC 3D65B23C nsMacMessageSink::IsRaptorWindow(GrafPort*)+0141C
16526620 PPC 3D65B87C nsMacMessageSink::IsRaptorWindow(GrafPort*)+01A5C
Comment 47•24 years ago
|
||
That stack doesn't tell us anything; we're just in the event loop.
Debugging this will require some combination of
1. PR logging
2. Network traffic watching
3. Instrumentation of the networking code in NSPR
Comment 48•24 years ago
|
||
Ping! This still regularly happens. It's about 1 in 3 on my Mac G4 450 os9.0.
Comment 49•24 years ago
|
||
Do we have a shortened iBench testbed that can demonstrate it?
Comment 50•24 years ago
|
||
pushing out. 0.9.2 is done. (querying for this string will get you the list of
the 0.9.2 bugs I moved to 0.9.3)
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 51•24 years ago
|
||
I set up a shortened version of 4 loops of 5 pages here:
http://dogspit/ibench/jrgm-bug-81480/perf_loadspeed.asp
But, that shortened version rarely shows the hang/spin (I only got it
once in 20 tries with my G4/450MHz, whereas I am about 1 in 3 when running
the full test on the same machine).
Comment 52•24 years ago
|
||
I was running current branch and trunk builds on two different Mac's, and
the failure rate was 50% (i.e., 1 in 2 tests don't complete).
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 53•24 years ago
|
||
Is anyone actively working this bug? IBench is an important external
performance measurement, hangs are more important than topcrashers to fix (since
we don't have any talkback mechanism to catch and report them.)
There was a suggestion that a build with some specific logging enabled was
needed, has that happened?
Comment 54•24 years ago
|
||
Nope, no-one is working on it.
Comment 55•24 years ago
|
||
This has been completing the test for the past week or so. There are still
problems associated with that test (bug 93603 ... there appears to be a
runaway UI thread at the end of the test), but this one is, for now,
worksforme.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 56•24 years ago
|
||
verified wfm: ran ibench 3 times, posted everytime
mac os9 2001-09-24-03-0.9.4
Status: RESOLVED → VERIFIED
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•