74118 - can't launch with a new profile

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Tracy Walker [:tracy]]

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

Comment 1

[Tracy Walker [:tracy]]

is this related to bug 74106?

Comment 2

[Grace Bush]

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

Comment 3

[Daniel (Leaf) Nunes]

can you verify this in a mozilla-only build?

Comment 4

[Doron Rosenberg (IBM)]

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

[Tracy Walker [:tracy]]

my bad...this has been seen on linux only

Comment 6

[Doron Rosenberg (IBM)]

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

Comment 7

[Doron Rosenberg (IBM)]

probably backend issue, reassigning

Comment 8

[Grace Bush]

Using an old profile - I launch but crash immediately

Comment 9

[Conrad Carlen (not reading bugmail)]

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?

Comment 10

[Conrad Carlen (not reading bugmail)]

OK. With my mozilla build, after creating a new profile and clicking "Start", it
just exited.

Comment 11

[Conrad Carlen (not reading bugmail)]

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().
 

Comment 12

[Doron Rosenberg (IBM)]

yeah, normal mozilla, not commercial. For the linux old profile issue, try
remoing the localstore.rdf file in the profile...

Comment 13

[Daniel (Leaf) Nunes]

so, can you step through to see where the exit is happening?

Comment 14

[Conrad Carlen (not reading bugmail)]

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.

Comment 15

[David :Bienvenu]

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

[saari (gone)]

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)

Comment 17

[Conrad Carlen (not reading bugmail)]

Chris - that sounds promising. How can I turn it off?

Comment 18

[Stuart Parmenter]

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...

Comment 19

[Conrad Carlen (not reading bugmail)]

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

[Peter Trudelle]

Downgrading to critical due to workaround - use new profile on subsequent 
launch.  cc saari & pav

Comment 21

[Brian Ryner (not reading)]

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

[Dan M]

  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.

Comment 23

[Brian Ryner (not reading)]

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

[Judson Valeski]

cc'ing darin -- possible file transport bug.

Comment 25

[Brian Ryner (not reading)]

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

[Darin Fisher]

Attachment: fixes the problem

Comment 27

[Darin Fisher]

-> myself

Comment 28

[Brian Ryner (not reading)]

r=bryner

Comment 29

[Scott MacGregor]

sr=mscott

Comment 30

[Darin Fisher]

fix checked in

Comment 31

[Grace Bush]

verify with build 2001040605