Can't submit bugzilla query

VERIFIED DUPLICATE of bug 24033

Status

()

Core
HTML: Form Submission
P3
critical
VERIFIED DUPLICATE of bug 24033
18 years ago
18 years ago

People

(Reporter: Biswapesh Chatterjee, Assigned: rpotts (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

18 years ago
System: Build 1999120608 on WinNT SP5
Overview: Mozilla goes into an infinite loop while executing query in bugzilla
under certain circumstances.
Test Case: Go to http://bugzilla.mozilla.org/query.cgi . Keeping all fields to
their default values, enter the string 'menu' in the field labeled 'Summary:'
and press 'Submit Query'. Keep NT task manager on.
Expected Result: The query results should be fetched.
Actual Result:
1) The following message starts appearing in an endless loop:
<<<
WARNING - table cell content max element width 1073751079 greater than desired
width 1073741824
>>>
2) The CPU Usage shoots to 100% and stays there till the browser is killed.
3) The page fills up with garbage.
4) The memory usage keeps on increasing.

Other info: This problem does not occur in M11, IE5, NS4.x, etc.
(Reporter)

Comment 1

18 years ago
The bug occurs even if you write 'scroll' instead of 'menu'. I think it can be
generalized for any query that returns a lot of bugs, but I'm not sure. Bug
remains with Dec. 12 build, except that the warnings about table size does not
show in the console window.

Updated

18 years ago
Assignee: karnaze → pollmann

Comment 2

18 years ago
I am not seeing an infinite loop but the query is not doing anything and reports
an "Error: Can't load ...". Reassigning to Eric.

Comment 3

18 years ago
I'm pretty sure that the current day failure to submit is a different bug from
that originally reported, and the original bug may still be lurking behind it.
I tried a query with last night's build and got this message:

url=(url+big query string)

data=(big query string)
DocLoaderFactory: Unable to create ContentViewer for command=view,
content-type=multipart/x-mixed-replace
Error: Can't load: (url+big query string)

Still looking at this.

Comment 4

18 years ago
Adding Rick to the CC list.

Updated

18 years ago
Summary: Infinite loop while executing query in bugzilla → Can't submit bugzilla query

Comment 5

18 years ago
The failure to submit a bugzilla query in today's build appears to be related to
Norris's checking yesterday to verify the security of a URL load.  I traced
through nsFormFrame::OnSubmit and we are bailing right in the new code:

 618       if (NS_FAILED(result) ||
 619           NS_FAILED(result = NS_NewURI(getter_AddRefs(actionURL), href)) ||
 620           NS_FAILED(result = securityManager->CheckLoadURI(docURL,
actionURL)))
 621       {
 622         return result;
 623       }
 624     }

result is not NS_OK here.  Anyone know why?  This failure is hiding yesterday's
bug even.  :S

Comment 6

18 years ago
Adding Judson to CC.

Comment 7

18 years ago
NS_NewURI is returning a failure code here.

Comment 8

18 years ago
The url is relative, "buglist.cgi" and the baseURI passed to NewURI is null,
this causes NS_ERROR_MALFORMED_URI in nsIOService::NewURI.  I'm looking into why
baseURI is null...

Comment 9

18 years ago
I'm attaching a 1 line fix for that bug, but I'm still seeing the "can't create
ContentViewer"...

Comment 10

18 years ago
Created attachment 3526 [details]
fix for today's form submission bug

Comment 11

18 years ago
*** Bug 21875 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
This fix will allow pages with forms with actions that are relative url's to
submit.  Unfortunately we will still have problems on the test URL because of
the contentViewer problem.  Would anyone like to review my first patch so we can
move on to the next problem?  Thanks.  :)

Comment 13

18 years ago
Created attachment 3528 [details]
test case

Comment 14

18 years ago
Created attachment 3529 [details]
oops, real test case

Updated

18 years ago
Assignee: pollmann → rpotts
Status: ASSIGNED → NEW

Comment 15

18 years ago
To verify the code fix, view the test case above labeled "opps, real test case".

Before the bug fix, clicking "submit" has not effect.
After the bug fix, clicking "Submit Query" has the effect of returning to this
bug report.
I'm checking in this fix, but leaving the bug open to track the contentViewer
problem.  Reassigning to rpotts, though I don't know if he's the right guy?

Comment 16

18 years ago
Checked in the first fix.

Updated

18 years ago
Summary: Can't submit bugzilla query → [DOGFOOD] Can't submit bugzilla query
(Assignee)

Comment 17

18 years ago
hey eric,
I've just pulled you fix and it fixes bugzilla for me!!  I don't see the "unable
to create content-viewer" error message...

Are you the only one seeing this message?

-- rick

Comment 18

18 years ago
*** Bug 21934 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Target Milestone: M12

Comment 19

18 years ago
Boldly putting on M12 radar

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 20

18 years ago
this should be marked resolved, just seeing that the fix was checked in

Updated

18 years ago
Whiteboard: [PDT+]

Comment 21

18 years ago
Putting on PDT+ radar.  Should this reopen, it is definitely dogfood for QA :-)

Comment 22

18 years ago
Rick, I am able to run bugzilla queries without seeing the "content-viewer"
message now.  Looks like this bug is all fixed now to me!  Thanks.  Now if only
typing in a textarea wasn't causing page downs this would really be bugzilla
dogfood.  :)
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 23

18 years ago
This is occurring again in 19991217 build (WinNT SP5) - Let me give you the
full URL:
http://bugzilla.mozilla.org/buglist.cgi?
bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substr
ing&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&changedin=
&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=menu&short_desc_type
=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=s
ubstring&status_whiteboard=&status_whiteboard_type=substring&cmdtype=doit&newque
ryname=&order=%22Importance%22&form_name=query
(Remove spaces and all which may have crept in due to form submission).
What is happening is I get a plain text list of the bug numbers at the top of
the page and then the mozilla.org GIF image (red dragon and all) a couple of
times. Then the app hangs. The CPU usage shoots to 100% and stays there (it has
remained there all the time I've been writing this report). The Mozilla.exe
process becomes 'Not responding', the memory usage keeps increasing and this
message comes in an infinite loop on the console window:
WARNING - table cell content max element width 1073741884 greater than desired w
idth 1073741824
I have the bugzilla cookie set.
This does not happen in IE5/Nav4.x/M11 - so there is no problem with the bug-
list.cgi script.
Another thing: I ran the same query with a simple cgi in the local web server
using mozilla and it runs fine. So the problem is not with the URL itself.
Can't think of any other detail (BTW the query is still running, mozilla is
still 'Not Responding', the table messages still appearing on the console
window and the CPU usage is still 100% as I finish writing this. It has been
about 5 minutes since I submitted the URL.

Re-opening this.

Updated

18 years ago
Resolution: FIXED → ---

Comment 24

18 years ago
I was able to submit Bugzilla query forms using the 12/17 opt comm bits on
Win98, but even the simplest query does not work in the debug build I just
finished. I had to switch to 4.7 to commit these changes to this bug. clearing
fixed resolution.
(Reporter)

Comment 25

18 years ago
Finally ! Got mozilla to crash so that I could get the crash dump. This time
there was no 'table...' message loop in the concole window - I was using a
different computer which did not have my cookie set - so this is not a cookie
problem either. This is what I got on my mozilla window upto the point it
crashed (Unfortunately I could not get a print screen - will try it later). The
query was just the word 'menu' in the summary field - the other fields were all
default; and as I said before, no cookies.
<<<
Set-Cookie:
BUGLIST=19588:9333:16722.....etc.
<The Mozilla Image>
Bugzilla version 2.8
>>>
The above got repeated with minor variations (Such as the date stamp comming
once and the mozilla image being a bit shorter, etc) till it crashed.
(Reporter)

Comment 26

18 years ago
Created attachment 3628 [details]
Dr. Watson crash log (two of them for the same incident)
(Reporter)

Comment 27

18 years ago
If you look at the attached crfash log, you will see that they crashed at
identical points, namely at the function NS_NewCSSNameSpaceRule. Any help from
that ?
(Reporter)

Comment 28

18 years ago
Very interesting: The browser *does not* crash if your bugzilla cookie is set -
it goes on an infinite loop instead with the table warning as below:
<<
WARNING - table cell content max element width 1073748829 greater than desired w
idth 1073741824
>>
That is why I was unable to get it to crash from my machine. I set my cookie
from this machine and was able to duplicate the behaviour of my m/c (namely no
crash, infinite loop, 100% CPU, infinite 'table..' error lop, the works.
(Reporter)

Comment 29

18 years ago
Sorry  - ignore the last message - it just crashed at the same point with the
cookie set - so no go there.
(Reporter)

Comment 30

18 years ago
Created attachment 3629 [details]
Clicking on the link in this HTML document will either crash mozilla or make it go into infinite loop.

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 31

18 years ago
This does not crash or infinite loop for me with today's build.  Fresh Win32
Clobber and Linux Depend builds from around noon today.  Marking WORKSFORME
because I don't know who fixed it.  Anyone still seeing this?

Updated

18 years ago
Status: RESOLVED → REOPENED

Comment 32

18 years ago
I'm seeing this with 1999122208 WinNT over 28.8K dialup (which may be a
factor). I've loaded the same HTML content from disk, and while it is a large
table, it loads from disk without any error.

This was noted in a message to n.p.m.general last night, and I could get it to
happen easily last night. However, oddly, this morning, at first, I couldn't
duplicate it.

When it does happen, the HTTP cookie header is displayed across the top of the
canvas. Note also that the query is generating a cookie of ~4K in size (which
is the minimum RFC requirement on cookie size, but in practice is the maximum
"in the wild" size of cookies, no?)

Speculating that this was networking related, and _may_ be timing sensitive, I
started an ftp download with Nav4.x to contend for my modem bandwidth. *Then*
I could duplicate this _twice_ this morning (it's hard to consistently
duplicate, but it is definitely there -- which, I know, sucks).

When the bug does occur:
 -- the cookie header displayed across the top of the screen,
 -- CPU -> 100%, memory starts going up,
 -- and, finally a crash [which occurs in NS_NewCSSNameSpaceRule, but that's a
    consequence of the Set-Cookie: mishandle, not the root cause (IMHO ;-)]

Updated

18 years ago
Resolution: WORKSFORME → ---
Target Milestone: M12

Comment 33

18 years ago
Clearing resolution, and target milestone (M12 has passed). Oh, and Happy
Holidays!

Comment 34

18 years ago
*** Bug 22334 has been marked as a duplicate of this bug. ***

Comment 35

18 years ago
Comments by mozilla-bugzilla@devin.com on bug #22334 (12/21/99):

 | M12 often hangs when displaying a bug list produced by Bugzilla's
 | buglist.cgi.  It may hang silently, or may rapidly (and eternally, AFAICT)
 | output errors of the form "WARNING - table cell content max element width
 | 1073741884 greater than desired width 1073741824", where the latter number
 | remains constant and the former may vary somewhat.  Layout in the browser
 | at this point contains black rectangles where images or tables would be
 | expected, above each of which is a Set-Cookie header, e.g. "Set-Cookie:
 | BUGLIST=18374:11586:...".  UI will not respond or redraw itself past that
 | point.  Screenshot at http://www.devin.com/cruft/hung-mozilla.jpeg if it's
 | useful.
 |
 | Bug may be reproduced by going to bugzilla via personal toolbar, then to
 | "Search existing bug reports."  Enter something in the "query" blank and
 | submit the form.

Updated

18 years ago
Target Milestone: M13

Comment 36

18 years ago
*** Bug 22039 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 37

18 years ago
This is working now.  Marking Resolved/WorksForMe.  paulmac to supply re-test
data.

Updated

18 years ago

Comment 38

18 years ago
bug 22039 has an URL that still causes the bug - which is clearly not working.

Updated

18 years ago
Resolution: WORKSFORME → ---
Summary: [DOGFOOD] Can't submit bugzilla query → Can't submit bugzilla query
Whiteboard: [PDT+]

Comment 39

18 years ago
John, I can't reproduce this using the test case in this bug or in bug 22039 on
Linux, win98, or winnt. Have you tried on a clean profile?

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 40

18 years ago
alright. I wiped my profile on 2000011311 on winNT and it worked fine. sorry for
the reopen spam that's an odd profile problem.

Comment 41

18 years ago
Marking VERIFIED WORKSFORME on:
- Linux6 2000-02-01-10 Commercial build
- Win98 2000-02-01-08 Commercial build
- MacOS86 2000-02-01-09 Commercial build
Status: RESOLVED → VERIFIED

Comment 42

18 years ago
*** Bug 24226 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 43

18 years ago
I'm getting this *yet again* on nightly build 20000208 on WinNT. Very 
frustrating. Just type something very common in the description field 
like 'java' or 'menu', which is sure to return a lot of entries, and submit.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 44

18 years ago
I'm unable to reproduce this using a tip build...

Comment 45

18 years ago
I am unable to repro this on a 02/12/99 build on winnt sp5

Comment 46

18 years ago
After an out-of-band exchange with paulmac (jan14), after this bug had
been closed, I filed this problem again with a new summary as bug #24033

So far, no one within Netscape has been able to reproduce this
behaviour, but at least six people outside your network have seen
this behaviour. (This suggests (to me) that connection speed and/or
round-trip latency may be a factor).

I think the key thing in all the reports of the this bug is that the
HTTP 'Set-cookie:' header is somehow put into the content sink -- see
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4272 -- which
should never happen (please correct me if this is an untrue statement). 

So, somewhere between necko, the parser and the content sink, the
wrong thing happens. (Perhaps the other critical condition is the
(near maximum) size of the cookie and/or the absolute size of the HTML
content returned for the query).

I'm going to mark this bug as a duplicate of bug #24033 (as it is a
dup). Of course, we still need a way to reproduce this, as it can't be
fixed otherwise. 

(Using win95 2000-02-10-14 I can't actually reproduce now, but I'm
always having some flaky service from my ISP right now so I can't
count this failure to reproduce as equal to no more problems.)

*** This bug has been marked as a duplicate of 24033 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 47

18 years ago
note that I can't repro the problem and I am outside the firewall (though I am 
on a T1 connection).

Comment 48

18 years ago
I haven't seen this bug in a while, but it doesn't have anything to do with bug
24033. I've seen both of these bugs - seperately. If someone wants to reopen
(assuming it's still happening for them) go right ahead.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 49

18 years ago
jelwell: did you intend to reopen this bug? (your comments indicate otherwise).

At any rate, this *is* the same bug as bug 24033 (which I opened as a 
'successor' to this bug after it was closed (see my Feb 13 comment above)). 

It sucks that this is difficult to duplicate, but there is a lurking problem
in the handoff necko->parser->content sink. It's better to focus the effort
in one place. Re-marking DUPL of bug 24033.

Comment 50

18 years ago
Duh! Now marking as a DUPL.

*** This bug has been marked as a duplicate of 24033 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 51

18 years ago
If someone reopened it, I don't think it was me. Or at least I hadn't intended 
too.

Comment 52

18 years ago
Marking VERIFIED DUPLICATE on:
- Linux6 2000-02-17-08 Commercial build
- MacOS9 2000-02-16-16 Mozilla build
- Win98 2000-02-16-16 Commercial build

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.