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

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.

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.

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.

view|page info crashes in the same function.

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

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 on attachment 160539 [details] [diff] [review] smaller fix Oops, consider that line removed rather than commented out.

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.

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

(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.

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.

got rid of ^M's and extra printfs

checked in.

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

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

I think this introduced bug 262310