linux only. Try creating a profile (not your initial one, a 2nd or above one) and run with it from the profile manager selector, it hangs. Quiting, and restarting, the profile works like it should and does not cause a hang. smoketest blocker (smoke test P.2, create another profile). Exists in tip and 0.9 branch.

keyword foo

conrad is away at Jury duty.

back - looking at it.

I've seen this before. Here's what happens: With the debugger, I can see that it returns from making the new profile and all is well. If I bring up the "Create Profile" dialog, cancel from it and choose another old profile which is known to work, I get the same hang. CC'ing darin because he figured this out last time. If I remember, it had to do with FileTransport service. In the meanwhile, I'll look for that bug.

CC'ing Dan (who was on this similar bug which I can't find) and Gagan.

Found the similar bug - it's bug 74118.

I'm seeing something similar with an initial profile (no ~/.mozilla) as well. (gdb) prun Breakpoint 1 at 0x80521bc: file ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1240. main (argc=1, argv=0x7ffff814) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1240 1240 InstallUnixSignalHandlers(argv[0]); [New Thread 25586 (manager thread)] [New Thread 25584 (initial thread)] [New Thread 25587] [New Thread 25588] *** Registering Proxy Auto Config (a Javascript module!) registerSelf for remoteControl [New Thread 25589] Registering plugin 0 for: "*","All types",".*" Program received signal SIGSEGV, Segmentation fault. 0x2c86851e in ?? () (gdb) bt #0 0x2c86851e in ?? () #1 0x2abb3729 in nsProxyObjectManager::GetProxyForObject (this=0x83fcf20, destQueue=0x0, aIID=@0x2b236754, aObj=0x2c868518, proxyType=6, aProxyObject=0x7fffe338) at ../../../../mozilla/xpcom/proxy/src/nsProxyObjectManager.cpp:200 #2 0x2b1c3ea5 in nsStreamLoader::Init () at ../../../mozilla/netwerk/build/nsNetModule.cpp:884 #3 0x2ba8d155 in NS_NewStreamLoader () at ../../../../../mozilla/content/xul/templates/src/nsXULTemplateBuilder.cpp:842 #4 0x2b8a67cb in CSSLoaderImpl::LoadSheet () at ../../../mozilla/content/build/nsContentModule.cpp:93 #5 0x2b8a7273 in CSSLoaderImpl::LoadStyleLink () at ../../../mozilla/content/build/nsContentModule.cpp:93 #6 0x2b91a5aa in XULContentSinkImpl::ProcessStyleLink () at ../../../mozilla/content/build/nsContentModule.cpp:93 #7 0x2b91ac91 in XULContentSinkImpl::AddProcessingInstruction () at ../../../mozilla/content/build/nsContentModule.cpp:93 #8 0x2b575e36 in CWellFormedDTD::HandleProcessingInstructionToken () at ../../../mozilla/htmlparser/src/nsParserModule.cpp:353 #9 0x2b575bdd in CWellFormedDTD::HandleToken () at ../../../mozilla/htmlparser/src/nsParserModule.cpp:353 #10 0x2b575648 in CWellFormedDTD::BuildModel () at ../../../mozilla/htmlparser/src/nsParserModule.cpp:353 #11 0x2b56deb2 in CNavDTD::CreateContextStackFor (this=0x2c81dcb0, aChildTag=eHTMLTag_unknown) at ../../../mozilla/htmlparser/src/CNavDTD.cpp:3864 #12 0x2b56dc29 in CNavDTD::AddLeaf (this=0x2c81dcb0, aNode=0x1) at ../../../mozilla/htmlparser/src/CNavDTD.cpp:3764 #13 0x2b56e9a6 in nsParser::OnDataAvailable () at ../../../mozilla/htmlparser/src/COtherElements.h:2225 #14 0x2b283dd3 in nsDocumentOpenInfo::OnDataAvailable () at ../../../mozilla/uriloader/build/nsURILoaderModule.cpp:64 #15 0x2b20d877 in nsJARChannel::OnDataAvailable () at ../../../../mozilla/netwerk/mime/src/nsXMLMIMEDataSource.cpp:343 #16 0x2b1b5553 in nsOnDataAvailableEvent::HandleEvent () at ../../../mozilla/netwerk/build/nsNetModule.cpp:884 #17 0x2b1b4c62 in nsARequestObserverEvent::HandlePLEvent () at ../../../mozilla/netwerk/build/nsNetModule.cpp:884 #18 0x2abaa343 in PL_HandleEvent (self=0x83fdd90) at ../../../mozilla/xpcom/threads/plevent.c:588 #19 0x2abaa1ec in PL_ProcessPendingEvents (self=0x806f778) at ../../../mozilla/xpcom/threads/plevent.c:518 #20 0x2abab80c in nsEventQueueImpl::ProcessPendingEvents (this=0x806f750) at ../../../mozilla/xpcom/threads/nsEventQueue.cpp:374 #21 0x2b75f413 in event_processor_callback () from /usr/cls/moz/main/obj-opt-22/dist/bin/components/libwidget_gtk.so #22 0x2b75f0c5 in our_gdk_io_invoke () from /usr/cls/moz/main/obj-opt-22/dist/bin/components/libwidget_gtk.so #23 0x2b0a7aca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #24 0x2b0a9186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #25 0x2b0a9751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #26 0x2b0a98f1 in g_main_run () from /usr/lib/libglib-1.2.so.0 #27 0x2afd15b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #28 0x2b75fb06 in nsAppShell::Run () from /usr/cls/moz/main/obj-opt-22/dist/bin/components/libwidget_gtk.so #29 0x2c11d21e in nsAppShellService::Run () ---Type <return> to continue, or q <return> to quit--- from /usr/cls/moz/main/obj-opt-22/dist/bin/components/libnsappshell.so #30 0x2c09b1be in ?? () from /usr/cls/moz/main/obj-opt-22/dist/bin/components/libprofile.so #31 0x2c09a716 in ?? () from /usr/cls/moz/main/obj-opt-22/dist/bin/components/libprofile.so #32 0x805051f in InitializeProfileService (cmdLineArgs=0x8353f48) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:783 #33 0x80512da in main1 (argc=1, argv=0x7ffff814, nativeApp=0x0) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:975 #34 0x8052352 in main (argc=1, argv=0x7ffff814) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1311 (gdb)

Ok, don't mind me. I'm not sure what I'm seeing. If I download this morning's nightly and run w/o ~/.mozilla, then I get prompted for to migrate my 4.x profile and things work as usual.

is this a blocker or not? It's currently marked a blocker, but the tree is open.

No fix yet, though I discovered a few things: (1) The main profile manager dialog has two modes: "selection" and "manage." Starting mozilla with -profilemanager brings up the dialog in "manage" mode. Creating a new profile when starting in this way will hang. However, starting it in "selection" mode (no args and you have > 1 profile) and then clicking the "Manage Profiles" button, you can create a new profile without hanging. (2) "I found the cause of the WARNING: XBL load did not complete until after dialog went away!" That has to do with the fact that when the "Start" button is clicked, the profile is set and then, immediately, profile dialog is destroyed. When the profile is set, the chrome registry responds and starts some XBL loads on the window which is on it way to being destroyed. The fix was to not have the profile mgr js code set the profile when "Start" is clicked. It now returns whether the user confirmed the dialog and the name of the chosen profile. Then, the back end can use this info to set the profile after the dialog is gone. That stops the assertions. Unfortunately, that didn't fix this problem.

This has nothing to do with profile back-end and happens only after a certain combination of modal dialogs. Changing component accordingly. Since linux-only, CC'ing blizzard.

reducing severity, the workarounds are pretty clear.

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

Blizzard, any chance you can look at this? Any other Linux debugging aces?

I installed today's build on Linux (2001-05-11-08-Mtrunk), it did not launch the browser if using the new profile. It did not crash. However, it worked fine with the existing profile though.

patty, try relaunching that new profile again. I've been able to get the new profiles to launch on reattempt

see the same problem on Solaris. add to cc list.

futuring this bug. we need someone w/ more linux debugging expertise to take it.

fe -> vishy

nav triage: not a netscape stopper.

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

hmm, this is a smoketest after all... adding helpwanted keyword

Excuse me, but "Future"? "not a netscape stopper"? You can't create a new profile on Linux and run the product, but this is considered to be a defect that the final product could ship with?

Renominating for reconsideration.

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

nav triage team: marking p2 and mozilla0.9.3

nav triage team: Forgot to add nsbeta1+

I hadn't tried this before, but with a current trunk build: ./mozilla -profilemanager Create Profile Next Finish Start Mozilla (with the newly created ("Default User") profile) launches fine. It could be that the fix for bug 84250 caught this bug as well. Closing. Verify?

I have not seen this for awhile- and for sure not today. will verify for build branch build 2001060606 adding vtrunk

danm is my hero! This works (creating new profile does not result in a hang with either branch or trunk comm. builds from today). Browser does not get hung.