Steps to reproduce: 1. gunzip/tar this build 2. remove ~/.mozilla 3. run ./netscape -installer Actual result: crash Talkback stack trace later

adding smoketest keyword to show up on blockers query.

changed component to profile manager, reassign to default component owner.

this is not Profile Manager- I am done with that before the crash-seamonkey comes up and bang! crash on launch -

I doubt this is Ben's bug either. Does anyone have a stack crawl on this?

I'll take it. I got a stack trace, I'll paste it in a second. note, you won't see this in the debug builds, but I'm fixing that problem when I fix this bug.

here's the stack trace: #0 0x4030f13b in nsDocShell::GetCurScrollPos (this=0x87cd360, scrollOrientation=1, curPos=0xbffff0a8) at nsDocShell.cpp:1683 #1 0x4030f363 in nsDocShell::SetCurScrollPos (this=0x87cd360, scrollOrientation=1, curPos=0) at nsDocShell.cpp:1712 #2 0x4031438c in nsDocShell::ScrollIfAnchor (this=0x87cd360, aURI=0x885a830, aWasAnchor=0xbffff458) at nsDocShell.cpp:2785 #3 0x403122c7 in nsDocShell::InternalLoad (this=0x87cd360, aURI=0x885a830, aReferrer=0x0, aWindowTarget=0x0, aPostData=0x0, aLoadType=<incomplete type>) at nsDocShell.cpp:2305 #4 0x403060c4 in nsDocShell::LoadURI (this=0x87cd360, aURI=0x885a830, aLoadInfo=0x0) at nsDocShell.cpp:215 #5 0x40318ce7 in nsRefreshTimer::Notify (this=0x885a8f0, aTimer=0x885a940) at nsDocShell.cpp:3529 #6 0x418b1707 in nsTimerGtk::FireTimeout (this=0x885a940) at nsTimerGtk.cpp:61 #7 0x418b1c9a in nsTimerExpired (aCallData=0x885a940) at nsTimerGtk.cpp:175 #8 0x40c288a4 in g_timeout_dispatch () #9 0x40c27a86 in g_main_dispatch () #10 0x40c28041 in g_main_iterate () #11 0x40c281e1 in g_main_run () #12 0x40b517a9 in gtk_main () #13 0x40a68a77 in nsAppShell::Run (this=0x80f8110) at nsAppShell.cpp:313 #14 0x40702ad4 in nsAppShellService::Run (this=0x80f61e0) at nsAppShellService.cpp:371 #15 0x80533d9 in main1 (argc=2, argv=0xbffff864, nativeApp=0x0) at nsAppRunner.cpp:904 #16 0x8053add in main (argc=2, argv=0xbffff864) at nsAppRunner.cpp:1188 #17 0x40553cb3 in __libc_start_main (main=0x8053918 <main>, argc=2, argv=0xbffff864, init=0x804ee70 <_init>, fini=0x805cf18 <_fini>, rtld_fini=0x4000a350, stack_end=0xbffff85c) at ../sysdeps/generic/libc-start.c:78

Note: I don't crash on my linux system and neither does Peter Mock or Fenella. However in the steps I don't do step#2 and we use existing profiles.

existing problems would not show the problem, because of the "first time start page". testing a potential fix....

on win32, there seems to be a crash very similar. Crash at console line Profile Manager : Profile Wizard and Manager activites : End. Not sure if this is related? We can;t get a better stack read on the crash.

windows2000 [today's build] mozilla.exe -console ... ProfileManager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End callstack 0101005c() GKGFXWIN! 60a8b434() i think this is the same bug, if not feel free to undo platform/os

ok, got a patch for the crash. even with this patch, we still assert like mad (in various places) and have problems. Index: base/nsDocShell.cpp =================================================================== RCS file: /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v retrieving revision 1.128 diff -p -r1.128 nsDocShell.cpp *** nsDocShell.cpp 2000/05/23 00:52:59 1.128 --- nsDocShell.cpp 2000/05/23 22:02:12 *************** NS_IMETHODIMP nsDocShell::GetRootScrolla *** 3244,3249 **** --- 3244,3252 ---- NS_ENSURE_SUCCESS(viewManager->GetRootScrollableView(aOutScrollView), NS_ERROR_FAILURE); + NS_ASSERTION(*aOutScrollView, "no scroll view"); + if (!*aOutScrollView) return NS_ERROR_FAILURE; + return NS_OK; } the first time start page really hoses us on linux, and that page exposes this problem. http://home.netscape.com/browsers/6/su_setup.html we get to it from a redirect (http://home.netscape.com/browsers/redirect/6/start.html) so maybe the re-direct is what is causing some of the problems.

partial fix checked in. that start page will still give us problems.

adding url.

Putting on [dogfood+] radar.

adding adam to the cc list. I think docshell is his baby now. adam, can you review what I checked in?

since the crash is gone, moving to critical. re-assigning to adam, so he decide when the bug is fixed. opened a new bug on http://home.netscape.com/browsers/6/su_setup.html causing hell and not displaying properly. #40354

marking fixed. #40354 is still open, though.

build 2000052320