Closed Bug 79179 Opened 24 years ago Closed 24 years ago

creating a new profile (not initial one) and trying to run with it causes hang

Categories

(SeaMonkey :: Startup & Profiles, defect, P2)

Product:
SeaMonkey
Component:
Startup & Profiles
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.3

People

(Reporter: doronr, Assigned: vishy)

References

Details

(4 keywords) 

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
Keywords: mozilla0.9.1, regression, relnote, smoketest
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.
Component: Profile Manager BackEnd → Profile Manager FrontEnd
reducing severity, the workarounds are pretty clear.
Severity: blocker → critical
*** 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.
Target Milestone: --- → Future
fe -> vishy
Assignee: ccarlen → vishy
nav triage: not a netscape stopper.
Keywords: nsbeta1-
*** Bug 83759 has been marked as a duplicate of this bug. ***
hmm, this is a smoketest after all...

adding helpwanted keyword
Keywords: helpwanted
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.
Keywords: nsbeta1- → nsbeta1
Target Milestone: Future → ---
*** Bug 83921 has been marked as a duplicate of this bug. ***
nav triage team:

marking p2 and mozilla0.9.3
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
nav triage team:

Forgot to add nsbeta1+
Keywords: nsbeta1 → 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?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I have not seen this for awhile- and for sure not today.
will verify for build branch build 2001060606
adding vtrunk
Keywords: 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.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.