262054 - Post 1.8a5 builds crashing at startup with profile manager [@ nsHTMLContainerFrame::CreateViewForFrame]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[tor]

A build of 9/28 evening past the checkin rush crashes at startup if
the profile manager tries to open.  If mozilla is started with -P foo
then everything is fine.

Top of the stack (optimized build) at time of crash:

#0  0x012039bb in nsHTMLContainerFrame::CreateViewForFrame(nsIFrame*, nsIFrame*,
int) () from /home/tor/mopt/dist/bin/components/libgklayout.so
#1  0x011fd002 in nsFrame::SetParent(nsIFrame const*) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so
#2  0x0129764a in nsBoxFrame::Init(nsPresContext*, nsIContent*, nsIFrame*,
nsStyleContext*, nsIFrame*) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so
#3  0x0125cee2 in nsCSSFrameConstructor::InitAndRestoreFrame(nsPresContext*,
nsFrameConstructorState&, nsIContent*, nsIFrame*, nsStyleContext*, nsIFrame*,
nsIFrame*) () from /home/tor/mopt/dist/bin/components/libgklayout.so
#4  0x0125b984 in nsCSSFrameConstructor::ConstructXULFrame(nsIPresShell*,
nsPresContext*, nsFrameConstructorState&, nsIContent*, nsIFrame*, nsIAtom*, int,
nsStyleContext*, nsFrameItems&, int, int&) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so
#5  0x0125de66 in nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell*,
nsPresContext*, nsFrameConstructorState&, nsIContent*, nsIFrame*, nsIAtom*, int,
nsStyleContext*, nsFrameItems&, int) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so
#6  0x0125dba0 in nsCSSFrameConstructor::ConstructFrame(nsIPresShell*,
nsPresContext*, nsFrameConstructorState&, nsIContent*, nsIFrame*, nsFrameItems&) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so
#7  0x01263bde in nsCSSFrameConstructor::ProcessChildren(nsIPresShell*,
nsPresContext*, nsFrameConstructorState&, nsIContent*, nsIFrame*, int,
nsFrameItems&, int, nsTableCreator*) () from
/home/tor/mopt/dist/bin/components/libgklayout.so
#8  0x0125ba13 in nsCSSFrameConstructor::ConstructXULFrame(nsIPresShell*,
nsPresContext*, nsFrameConstructorState&, nsIContent*, nsIFrame*, nsIAtom*, int,
nsStyleContext*, nsFrameItems&, int, int&) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so
#9  0x0125de66 in nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell*,
nsPresContext*, nsFrameConstructorState&, nsIContent*, nsIFrame*, nsIAtom*, int,
nsStyleContext*, nsFrameItems&, int) ()
   from /home/tor/mopt/dist/bin/components/libgklayout.so

Comment 1

[Andrew Schultz]

Attachment: full stack

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix for crash

This patch should fix the crash. We need to initialize things before we call
SetParent(), because nsFrame::SetParent() needs them.

[Seems like nsBoxFrame::Init duplicates a lot of nsFrame::Init, maybe something
can be removed.]

In my build, the Profile Manager proceeds to start up with the profile names
invisible. But this could be because I have a huge block+line patch for margin
collapsing that I've only just finished coding up and no doubt has all sorts of
problems.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I removed my margin-collapse patch and rebuilt what I believe is the trunk, and
it doesn't crash but the profile names are still all invisible :-(. So we've got
a serious smoketest blocker on our hands.

Comment 4

[Tobias Fischer]

Well, have seen this crash too starting with two Profiles installed from the
first 1.8a5 Builds, must be Build ID 2004092812, running Windows 2000. 
This crash seems to be an regression caused by one of the checkins after opening
the Trunk for 1.8a5 and 12:00 PST. 

The newe Mozilla Builds are starting up with only one Profile, but then crashing
opening MailNews, think this would be the similar crasher. 

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

view|page info crashes in the same function.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 7

[Brian Ryner (not reading)]

Attachment: smaller fix

I'd rather do it this way... nsBoxFrame no longer needs to override SetParent,
which means we're just calling nsContainerFrame::SetParent, which (as far as
we're concerned) just initializes mParent, which nsFrame::Init does as well.

However, once I've applied this patch to fix the crash, I see tree weirdness in
Thunderbird... the folder pane doesn't paint anything, and neither does the
tree in the account manager dialog.  Still trying to debug that, but help would
be welcome.

Comment 8

[Brian Ryner (not reading)]

Comment on attachment 160539 [details] [diff] [review]
smaller fix

Oops, consider that line removed rather than commented out.

Comment 9

[David :Bienvenu]

the folder pane paints the totals columns if you have them, just not the folder
name column. The thread pane looks ok.

I don't know why the name column would be messed up - it's the first column, but
I don't know why that would be special.

Comment 10

[Jon Granrose]

we need to start backing things out if this is going to run into tomorrow's
build cycle.

Comment 11

[Tobias Fischer]

(In reply to comment #7)
> 
> However, once I've applied this patch to fix the crash, I see tree weirdness in
> Thunderbird... the folder pane doesn't paint anything, and neither does the
> tree in the account manager dialog.  Still trying to debug that, but help would
> be welcome.
> 
Now running Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5)
Gecko/20040929 Mnenhy/0.6.0.104 {Build ID 2004092914} and luky that your patch
fix the crasher here. 
But also in Seamonkey I see the above discribed tree weirdness, in the
Folderpane, Preferences Dialogue, ProfileManager, Sidebar nothing was paint. Hmm.  

Comment 12

[Brian Ryner (not reading)]

Attachment: patch for tree weirdness

This fixes the tree painting problems, I hope.	The problem was with
nsBoxFrame::RelayoutChildByOrdinal.  I mistakingly left SetNextBox present but
unimplemented (this was the only caller) and that caused the first column to be
deleted when ordinals are used.  This patch removes dependency on SetNextBox,
and in the process, simplifies this function quite a bit.

Comment 13

[Brian Ryner (not reading)]

Attachment: cleaned up tree patch

got rid of ^M's and extra printfs

Comment 14

[Brian Ryner (not reading)]

checked in.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

sorry, I noticed the XUL tree printfs and forgot to mention it.

Comment 16

[David :Bienvenu]

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

Comment 17

[David :Bienvenu]

I think this introduced bug 262310