can't launch with a new profile

VERIFIED FIXED in mozilla0.9



18 years ago
18 years ago


(Reporter: tracy, Assigned: Darin Fisher)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
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


18 years ago
Keywords: smoketest

Comment 1

18 years ago
is this related to bug 74106?

Comment 2

18 years ago
logged bugscape bug 4503- this appears  to fail on activation with new or newly
migrated profile.

Comment 3

18 years ago
can you verify this in a mozilla-only build?

Comment 4

18 years ago
mozilla 2001033004 win98, cannot reproduce this. I can create a new profile and
surf with it (i am even submitting this with it).

Comment 5

18 years ago
my bad...this has been seen on linux only
OS: Windows 98 → Linux

Comment 6

18 years ago
and I can reproduce it on linux (today, self built).  Exact same behaviour.

Comment 7

18 years ago
probably backend issue, reassigning
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd

Comment 8

18 years ago
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...

Comment 13

18 years ago
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:
Trying to narrow it down a bit.

Comment 15

18 years ago
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.

Comment 16

18 years ago
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?

Comment 18

18 years ago
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.


Comment 20

18 years ago
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?

Comment 22

18 years ago
  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 
  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.

Comment 24

18 years ago
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.

Comment 26

18 years ago
Created attachment 29461 [details] [diff] [review]
fixes the problem


18 years ago
Assignee: ccarlen → darin
Component: Profile Manager BackEnd → Networking

Comment 27

18 years ago
-> myself


18 years ago
Keywords: nsbeta1, patch
Target Milestone: --- → mozilla0.9

Comment 29

18 years ago

Comment 30

18 years ago
fix checked in
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 31

18 years ago
verify with build 2001040605
You need to log in before you can comment on or make changes to this bug.