Closed Bug 74118 Opened 24 years ago Closed 24 years ago

can't launch with a new profile

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: tracy, Assigned: darin.moz)

Details

(Keywords: smoketest)

Attachments

(1 file)

fixes the problem
1.55 KB, patch
Details | Diff | Splinter Review
seen on commercial build 2001-03-30-05-mtrunk -create a new profile from the profile manager -launch the browser with the new profile the console shows: ProfileManager : CreateNewProfile Profile Name: Default User Profile Dir: /u/twalker/.mozilla ProfileManager : StartApprunner profileName passed in: Default User here is just hangs sometimes sometimes it returns me to my >prompt either way it doesn't launch the app. I am making this a blocker because part of the loadtime testing requirement is to run it with a new profile
Keywords: smoketest
is this related to bug 74106?
logged bugscape bug 4503- this appears to fail on activation with new or newly migrated profile.
can you verify this in a mozilla-only build?
mozilla 2001033004 win98, cannot reproduce this. I can create a new profile and surf with it (i am even submitting this with it).
my bad...this has been seen on linux only
OS: Windows 98 → Linux
and I can reproduce it on linux (today, self built). Exact same behaviour.
probably backend issue, reassigning
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd
Using an old profile - I launch but crash immediately
My linux build is just finishing up. Will look at it. > and I can reproduce it on linux (today, self built) Is this commercial only or mozilla as well?
OK. With my mozilla build, after creating a new profile and clicking "Start", it just exited.
On linux, after stepping through, it successfully makes it through all profile-related code. In nsAppRunner.cpp, it returns successfully from InitializeProfileService() and makes it as far as calling appShell->Run().
yeah, normal mozilla, not commercial. For the linux old profile issue, try remoing the localstore.rdf file in the profile...
so, can you step through to see where the exit is happening?
No, actually it doesn't exit - it just hangs. It does so after entering the main loop here: http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#1021 Trying to narrow it down a bit.
I saw this happen on an existing profile with a debug build from this morning - it only happened once, and it printed out an error to the console about being unable to get the app service, I think it was.
libpr0n got turned on for linux, so you might want to try building with it turned off to see if it is the cause (sorry, my linux box is headless right now)
Chris - that sounds promising. How can I turn it off?
run configure --disable-libpr0n I don't think this is the bug, and doing a new build is going to take probably 2 hours, so we wouldn't know until almost 7pm, and then we have to find a fix if it is the problem, and if it isn't...
It does not seem to be with the creation of the profile itself. When I create the new profile, it returns successfully from profile initialization, continues with more initialization in AppRunner, enters the main event loop and hangs. Next time around, if I pick that same profile and start, the app launches fine. That says the profile is OK. Another thing: If I bring up the create proifle wizard, do nothing but cancel, then pick an existing good profile, the app still hangs in the same way. Summary: Showing the create profile wizard brings about the problem but long after it's gone.
Downgrading to critical due to workaround - use new profile on subsequent launch. cc saari & pav
Severity: blocker → critical
I did some investigation here. It looks like what's happening is that we get a hang when the FileTransport tries to get a proxy (to the main thread) for the StreamIOChannel. This is all happening during the load of about:blank for creating the hidden window. Since this only manifests itself when the create profile wizard is shown, I think what we have here is a bug that happens when a modal dialog is shown before the hidden window is created. Something must be getting mucked up with the event queue. Changing the create profile wizard to a non-modal dialog makes the problem go away. Dan, any ideas?
what the! Apparently the way we do I/O has changed drastically; my event queue debugging lines in nsAsyncStreamListener are no longer even hit. So I'm not sure. But that pile of "...XBL load did not complete until after document went away! Modal dialog bug?" warnings is a pretty good indication that the modal event queue magic has stifled some important connections that shouldn't have been stifled. It's a nasty problem. But my suggestion to fix this bug would be to do as Brian says: make the profile wizard non-modal. It's the only window on the screen for petessake. Thanks for tracking that down, Brian.
dan, actually it's not the only window on the screen. The window I'm referring to is the Create Profile wizard, which you get to by hitting the Create button in the profile selection dialog. So there are two windows.
cc'ing darin -- possible file transport bug.
Darin and I figured this out. There are a pair of leaks in nsStreamIOChannel that are eventually causing the modal window's event queue to leak (and never be removed from the chain). We should really make the event queue code more robust so that leaking an event queue doesn't mess things up this much.
Assignee: ccarlen → darin
Component: Profile Manager BackEnd → Networking
-> myself
Status: NEW → ASSIGNED
Keywords: nsbeta1, patch
Target Milestone: --- → mozilla0.9
r=bryner
sr=mscott
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verify with build 2001040605
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: