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)

PowerPC
Mac System 9.x
defect

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
lets try dougt...
Assignee: cathleen → dougt
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
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
doug, any updates on this bug?? :-)
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 → ---
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.
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!!
I always delete the cache before running the test. But I will try the other items that you mentioned.
Blocks: 71668
reassigning to gagan.
Assignee: dougt → gagan
Status: REOPENED → NEW
is this working now?
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Unknown. I can't even get through an ibench run (it throws PDF and other crap at me, which puts up download dialogs).
simon: try running just the html page load tests.
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.
gagan, any updates on this? have we figured out what's causing result page not get posted?
no updates. Anyone is welcome to take this bug from me if they want...
gagan, this bug is creeping back again... on Friday's build. :-) see http://slip/projects/mojo/perf/i-bench.html
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 ago24 years ago
Resolution: --- → WORKSFORME
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]
"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?
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
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)
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).
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 ago24 years ago
Resolution: --- → WORKSFORME
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 → ---
Priority: -- → P2
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?
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).
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.)
Might also want to run with Intararchy's traffic watching feature turned on.
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
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.
Do we need to be getting a tracer on a separate system between the client and sever, or is there some other problem?
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").
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.
As bbaetz and I discussed, he wasn't running on Mac, and this is a Mac-only bug.
Whiteboard: [ibench] → [ibench] mac only
Note that the fix in bug 85514 might help this.
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.
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.)
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.
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.
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).
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.
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
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
Ping! This still regularly happens. It's about 1 in 3 on my Mac G4 450 os9.0.
Do we have a shortened iBench testbed that can demonstrate it?
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
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).
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).
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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?
Nope, no-one is working on it.
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 ago24 years ago
Resolution: --- → WORKSFORME
verified wfm: ran ibench 3 times, posted everytime mac os9 2001-09-24-03-0.9.4
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.