From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020812 BuildID: sometime today, cvs build every time I visit a bugzilla page with a current cvs build, I get a hang and have to kill mozilla. sorry for not choosing a component, don't know where it belongs Reproducible: Always Steps to Reproduce: 1.launch mozilla cvs build 2.visit a bugzilla page, e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=18502 3. Actual Results: mozilla freezes, does not repaint the window, does not react to any key presses or mouseclicks. title bar does change to the page's title, though Expected Results: page should be displayed

cartman was seeing this bug too and pointed out that it happened only for bugzilla pages (also on linux)

Also hangs using 2002-08-14-04, Linux.

Could it have to do with Bugzilla cookies? I often have to remove one when Mozilla won't load Bugzilla pages anymore. (Bug 121800)

Trunk CVS build including checkins at 08/14/2002 06:00 does not show the bug (linux) (I deleted component.reg before starting new builds)

rkaa, which time zone is that 06.00 in? PDT?

Removed component.reg cleaned all cookies still freezing in bugzilla pages with latest cvs.

a build by me which was finished 11:58 CEST (GMT +0200) showed this behaviour. as config.cache has a last-mod time of 10:33 CEST and as I deleted it before this build, the checkin must have been before that.

ok, the 06.00 can't be PDT :) I'll just assume that it is +0200, which gives this bonsai query: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=08%2F13%2F2002+21%3A00&maxdate=08%2F14%2F2002+01%3A33&cvsroot=%2Fcvsroot which shows that the patch by henry.jia@sun.com for bug 75081 might be responsible. cc'ing him here. I'll try backing his patch out locally to see if it fixes the hang.

Adding smoketest keyword so this shows up on the blocker list.

now that's interesting. a debug build shows an insane amount of assertions, like these: Break: at file /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3766 ###!!! ASSERTION: redo line on totally empty line: 'aState.IsImpactedByFloater()', file /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3764 Break: at file /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3764 ###!!! ASSERTION: unconstrained height on totally empty line: 'NS_UNCONSTRAINEDSIZE != aState.mAvailSpaceRect.height', file /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3766 and in the end, I get: Block(td)(7)@0x87b91c8: yikes! spinning on a line over 1000 times! Abort stack trace: #0 0x406b4581 in kill () from /lib/libc.so.6 #1 0x4033d94e in pthread_kill () from /lib/libpthread.so.0 #2 0x4033de29 in raise () from /lib/libpthread.so.0 #3 0x406b58d1 in abort () from /lib/libc.so.6 #4 0x402f54bb in PR_Abort () at /home/chb/mozilla/nsprpub/pr/src/io/prlog.c:482 #5 0x402a0ba3 in nsDebug::Abort(char const*, int) (aFile=0x415d4a60 "/home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp", aLine=3558) at /home/chb/mozilla/xpcom/glue/nsDebug.cpp:420 #6 0x413aa1b5 in nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&, nsLineList_iterator, int*, int, int) (this=0x87b91c8, aState=@0xbfffaa80, aLine= {mCurrent = 0x8803ef8, mListLink = 0x87b9204}, aKeepReflowGoing=0xbfffa818, aDamageDirtyArea=0, aUpdateMaximumWidth=0) at /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp:3558 #7 0x413a7f87 in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, int*, int) (this=0x87b91c8, aState=@0xbfffaa80, aLine= {mCurrent = 0x8803ef8, mListLink = 0x87b9204}, aKeepReflowGoing=0xbfffa818, aDamageDirtyArea=0) at /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp:2628 #8 0x413a6f3d in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) (this=0x87b91c8, aState=@0xbfffaa80) at /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp:2272 #9 0x413a3f4a in nsBlockFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) (this=0x87b91c8, aPresContext=0x86f0270, aMetrics=@0xbfffaf40, aReflowState=@0xbfffae70, aStatus=@0xbfffb0bc) at /home/chb/mozilla/layout/html/base/src/nsBlockFrame.cpp:949 #10 0x413c1cd3 in nsContainerFrame::ReflowChild(nsIFrame*, nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned, unsigned&) ( this=0x87b9168, aKidFrame=0x87b91c8, aPresContext=0x86f0270, aDesiredSize=@0xbfffaf40, aReflowState=@0xbfffae70, aX=19, aY=19, aFlags=0, aStatus=@0xbfffb0bc) at /home/chb/mozilla/layout/html/base/src/nsContainerFrame.cpp:806 #11 0x414f22b5 in nsTableCellFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) (this=0x87b9168, aPresContext=0x86f0270, aDesiredSize=@0xbfffb1e0, aReflowState=@0xbfffb0c0, aStatus=@0xbfffb0bc) at /home/chb/mozilla/layout/html/table/src/nsTableCellFrame.cpp:944 #12 0x413c1cd3 in nsContainerFrame::ReflowChild(nsIFrame*, nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned, unsigned&) ( this=0x87b8c54, aKidFrame=0x87b9168, aPresContext=0x86f0270, aDesiredSize=@0xbfffb1e0, aReflowState=@0xbfffb0c0, aX=5909, aY=0, aFlags=0, aStatus=@0xbfffb0bc) at /home/chb/mozilla/layout/html/base/src/nsContainerFrame.cpp:806 #13 0x41514f71 in nsTableRowFrame::ReflowChildren(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, nsTableFrame&, unsigned&, int) (this=0x87b8c54, aPresContext=0x86f0270, aDesiredSize=@0xbfffb480, aReflowState=@0xbfffb3b0, aTableFrame=@0x8760e98, aStatus=@0xbfffc1f0, aDirtyOnly=0) at /home/chb/mozilla/layout/html/table/src/nsTableRowFrame.cpp:1040 #14 0x415162c7 in nsTableRowFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) (this=0x87b8c54, aPresContext=0x86f0270, aDesiredSize=@0xbfffb480, aReflowState=@0xbfffb3b0, aStatus=@0xbfffc1f0) at /home/chb/mozilla/layout/html/table/src/nsTableRowFrame.cpp:1443 #15 0x413c1cd3 in nsContainerFrame::ReflowChild(nsIFrame*, nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned, unsigned&) ( this=0x8760fa8, aKidFrame=0x87b8c54, aPresContext=0x86f0270, aDesiredSize=@0xbfffb480, aReflowState=@0xbfffb3b0, aX=0, aY=3952, aFlags=0, aStatus=@0xbfffc1f0) at /home/chb/mozilla/layout/html/base/src/nsContainerFrame.cpp:806 #16 0x41517e7f in nsTableRowGroupFrame::ReflowChildren(nsIPresContext*, nsHTMLReflowMetrics&, nsRowGroupReflowState&, unsigned&, nsTableRowFrame*, int, nsTableRowFrame**, int*) (this=0x8760fa8, aPresContext=0x86f0270, aDesiredSize=@0xbfffb830, aReflowState=@0xbfffb580, aStatus=@0xbfffc1f0, aStartFrame=0x0, aDirtyOnly=1, aFirstRowReflowed=0xbfffb57c, aPageBreakBeforeEnd=0x0) at /home/chb/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp:443 #17 0x4151ac82 in nsTableRowGroupFrame::IR_TargetIsMe(nsIPresContext*, nsHTMLReflowMetrics&, nsRowGroupReflowState&, unsigned&) (this=0x8760fa8, aPresContext=0x86f0270, aDesiredSize=@0xbfffb830, aReflowState=@0xbfffb670, aStatus=@0xbfffc1f0) at /home/chb/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp:1431 #18 0x4151a5b1 in nsTableRowGroupFrame::IncrementalReflow(nsIPresContext*, nsHTMLReflowMetrics&, nsRowGroupReflowState&, unsigned&) (this=0x8760fa8, aPresContext=0x86f0270, aDesiredSize=@0xbfffb830, aReflowState=@0xbfffb670, aStatus=@0xbfffc1f0) at /home/chb/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp:1285 ...let me know if more of the stack is needed I still have to try a build w/o henry.jia's checkin.

Re comment 5: The time i pasted was copied from bonsai.

note that I'm not 100% sure if the debug stack I pasted here corresponds to the hang also, I have to contradict rkaa - I started my build long before the 06:00 checkins (as mentioned above, I started it at 01:33 PDT, which is bonsai's timezone)...

i just pulled and built again - no problems here. There was a second checkin v1.91 of mozilla/string/obsolete/nsStr.cpp, around 31 minutes after the first one (a fix for the fix for bug 75081?) - is that the one you build with?

I'm using bugzilla right now with a current cvs build and I haven't seen any hangs yet.

Is anyone who's seeing this using XBL form controls? I'm not.

i see no hang on mozilla pages, but i crash hard on one of my own ugly homepages.. http://home.c2i.net/dark/linux.html the stack indicates table/frame related problems. Maybe caused by checkin for bug 159359 - top of stack pasted there

WFM Linux nighty verification 2002-08-14-04.

does NOT wfm using 2002081404

interestingly, this works just fine if I save the bugzilla page locally and open it from there.

I had the same with the forum on racing1.de (and with bugzilla) - which is allowed to set a cookie here... both not reproducable..

I've seen this hang twice, both times after attaching files to bugzilla. (In both cases, the files were successfully attached.)

OK, I just saw it a third time, right after submitting this comment. And *that* wasn't an attachment. The stacks pointed to layout. Is it correct that nobody saw this in yesterday's builds?

I can reproduce this much more reliably by loading a bonsai query, such as http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-08-13+08%3A00&maxdate=2002-08-14+04%3A00&cvsroot=%2Fcvsroot which is the list of checkins that are under suspicion at the moment (I wish we had evening builds from yesterday!).

I am no longer able to reproduce the hang on the bonsai page above after backing out shanjian's checkin for bug 161328 in my tree.

yeah, that fixes my problems too

The hang itself, by the way, is the infinite loop described in comment 10 -- LINE_RFELOW_REDO status is being returned in a case where it shouldn't be, so we redo the line and get the same result over and over again.

LINE_REFLOW_REDO, rather.

shanjian is looking at this

backed out my change for 161328. Mark this one fixed.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&date=hours&hours=2&mindate=&maxdate=&cvsroot=%2Fcvsroot shows no backout...

oh now it does. was probably just bonsai being slow.

*** Bug 162770 has been marked as a duplicate of this bug. ***