Results page not being posted to client after ibench run

VERIFIED WORKSFORME

Status

SeaMonkey
General
P2
critical
VERIFIED WORKSFORME
17 years ago
13 years ago

People

(Reporter: Paul Wyskoczka, Assigned: Gagan)

Tracking

({hang})

Trunk
mozilla0.9.4
PowerPC
Mac System 9.x

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ibench] mac only, URL)

(Reporter)

Description

17 years ago
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

Comment 1

17 years ago
Mac platform now...
Gagan, who on your team can we get some help from??
Hardware: PC → Macintosh
(Assignee)

Comment 2

17 years ago
lets try dougt...
Assignee: cathleen → dougt

Comment 3

17 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

17 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 5

17 years ago
doug, any updates on this bug??  :-)

Comment 6

17 years ago
Paul, when did this stop working?  Did it ever work?  Are there other known 
posting bugs?

Comment 7

17 years ago
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?
(Assignee)

Comment 8

17 years ago
Seems like this is working again. Closing as such... 
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 9

17 years ago
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

17 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

17 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

17 years ago
I always delete the cache before running the test.  But I will try the other
items that you mentioned.

Updated

17 years ago
Blocks: 71668

Comment 13

17 years ago
reassigning to gagan.  
Assignee: dougt → gagan
Status: REOPENED → NEW

Comment 14

17 years ago
is this working now?

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 15

17 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

17 years ago
simon: try running just the html page load tests.
(Reporter)

Comment 17

17 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

17 years ago
gagan, any updates on this?
have we figured out what's causing result page not get posted?
(Assignee)

Comment 19

17 years ago
no updates. Anyone is welcome to take this bug from me if they want...

Comment 20

17 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

17 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
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 22

17 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

17 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

17 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

17 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

17 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

17 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
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 28

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

Updated

17 years ago
Priority: -- → P2
(Assignee)

Comment 29

17 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

17 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

17 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

17 years ago
Might also want to run with Intararchy's traffic watching feature turned on.

Comment 33

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

17 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

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

17 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

17 years ago
Note that the fix in bug 85514 might help this.

Comment 40

17 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

17 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

17 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

17 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

17 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

17 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

17 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

17 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

17 years ago
Ping! This still regularly happens. It's about 1 in 3 on my Mac G4 450 os9.0.

Comment 49

17 years ago
Do we have a shortened iBench testbed that can demonstrate it?

Comment 50

17 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

17 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

17 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

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 53

17 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

17 years ago
Nope, no-one is working on it.

Comment 55

17 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
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 56

17 years ago
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.