39289 - CRASH 0xC0000005: Access Violation. [win32 talkback, nightly]

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[timeless]

I request that reporters/reviewers READ each of my bugs THOROUGHLY before 
marking them as dupes, I will be using the same syntax for each of a series of 
bugs.

2000051420 win32 talkback [speculative, see bug 39266]
nt4sp6a 1381

\\129.2.204.205\mozilla\bin\mozilla -console -jsconsole -CreateProfile new 
d:\temp\users50
According to lxr: 
http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#480
// apprunner -CreateProfile "profilename profiledir" 
// creates a new profile named <profilename> and sets the directory to 
<profiledir> 
// runs app using that profile 
stdout directed to dynamic console
stderr directed to dynamic console
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
profileName & profileDir are: new
ProfileManager : CreateNewProfile
Profile Name: new
Profile Dir: \\129.2.204.205\mozilla\Users50
NKRES! 00ea19c2()
NKRES! 00ea1aed()
UCONV! 60814a2b()
UCONV! 60813e40()
\\129.2.204.205\mozilla\bin\mozilla -console -jsconsole -CreateProfile "new 
d:\temp\users50"
also generates the same call stack but the following output:
stdout directed to dynamic console
stderr directed to dynamic console
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin

Expected behavior: one of the two command lines should work.

Comment 1

[leger]

Putting "crash" in keyword field.

Comment 2

[Asa Dotzler [:asa]]

XPApps handles comandline issues.

Comment 3

[sairuh (rarely reading bugmail)]

grace, d'you see this?

Comment 4

[Grace Bush]

from bug 38315

There has been a behavioral change for -CreateProfile option. It now creates a 
profile and quits the app. This was the behavior planned for the users who want 
to use our app to just create a profile without UI and quit. Sorry, I didn't 
notify this change to the broader audience except QA. 

What you are seeing is not a crash- rather splash comes up while profile being 
created and stops.
----------------------
adding racham to cc list
Bhuvan,
Comments in 
http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#480
should be changed to reflect new behavior
Should the splash screen come up- this does make you think you should be 
launching?

Comment 5

[timeless]

Personally, for this purpose, I'd prefer no splash screen and maybe a debug 
warning reminding me that the app will need to be run again.

<blockquote>What you are seeing is not a crash- rather splash comes up while 
profile being created and stops.</blockquote>
NKRES! 00ea19c2()
NKRES! 00ea1aed()
UCONV! 60814a2b()
UCONV! 60813e40()
is my call stack when it crashed.

Comment 6

[don]

Removing "crash" keyword.

Bhuvan, do you want to change the behavior?

Comment 7

[racham]

I am sorry...I forgot to update comments for -CreateProfile when I fixed 
behavior. However, we are going to release note that the way -CreateProfile is 
going to work. In order to not to see the splash screen, one should also pass 
-nospalsh (that is the simplest solution) in the command line arguments. i.e., 
mozilla -nospalsh -createprofile "foo c:\bar".

This should not cause a crash i.e., creating a profile using -CreateProfile. I 
haven't experienced it. Grace did you ever get a crash..?

If this bug is to address the change in behavior for -CreateProfile option, then 
this should be closed invalid and we will make sure that the change in behavior 
goes into release notes.

Comment 8

[leger]

Adding crash keyword

Comment 9

[racham]

I think this bug is talking about the way app is quitting after doing a profile 
creation when -CreateProfile is used.. Though it was different in the past, the 
functionality is to quit the profie and quit the app.. I will talk to verah to 
put this item inthe release note. I am closing this bug invalid..

Comment 10

[Grace Bush]

.

Comment 11

[timeless]

fwiw, this bug is talking about crashing, not quiting.
I don't mind quiting. [Thank you for updating your code comments]
I think that this problem is another of the readonly directory issues.

So here's my question, what files does this commandline need to touch?

\\readonlyserver\mozilla\bin\mozilla -console -jsconsole -CreateProfile new 
d:\temp\users50
I have full ownership of d:\temp\users50 i have read/execute/filescan privs for 
the unc.
see also bug 39282 

I should probably highlight this line:
Profile Dir: \\129.2.204.205\mozilla\Users50
I'm trying to tell moz to use d:\temp\users50
I'm going to test this today. It's possible that w/ my clarifications this a 
dupe or fixed.  I'm sorry for the delay.

Comment 12

[racham]

The solution should be in line with fix for bug 39282.

Adding keyword nsbeta3.

Comment 13

[selmer (gone)]

Adding nsbeta3+ for the moment.  Please mark this dup if it is.  Has this been
verified?

Comment 14

[Grace Bush]

reproduced on build 
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-08-09-09-M18/

also tested on pr2 build (2000080712) and did not crash

Comment 15

[Daniel Veditz [:dveditz]]

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up

Comment 16

[racham]

[e-mail], I just checked in the fix for the crash that occurs with 
CreateProfile option. Can you verify on your end too...?

Couple of things here...

1. Note that if you are going to provide a profile location (that means giving 
the profile directory path in the command line option), you need to enclose the 
profile name and profile directory in double quotes..

So, say if you are going to create a profile foo under dir c:\bar, the syntax 
for total createprofile option is 

mozilla -createprofile "foo c:\bar". 

That a creates profile foo in the registry and puts all default profile contents 
under c:\bar\foo.

If you don't enclose them in double quotes, just the first argument is processed  
and chooses the default location for this profile.

2. In the past, you seemed to have experinced crashes we couldn't reproduce 
here..So, please let me if you have build environment and make builds daily. If 
that is the case, I can post probable patches that you can verify on your 
end..Also if you can reproduce this bug, update the bug with any stack traces 
you get.

Comment 17

[Daniel Bratell]

So it's impossible (hard) to create profiles in directories with spaces in?

Comment 18

[timeless]

I don't have a win32 build env. Unless someone is willing to buy MSVC and give 
it to me I will probably never have the standard build env.  I did get advice 
about a place to go to read about mingw32 so I might have a non std build env 
in the future.  I think some of my features are from multiuser, readonly and 
odd home settings. (Possibly mozilla was reading from one components.reg and 
trying to right to the normal one so it never healed..) I presume I should wait 
until tomorrow?

mozilla -createprofile "foo c:\bar". 
Um. Ok, but I think someone needs to file a bug, the syntax should be closer 
to:
mozilla -createprofile foo "c:\bar" which would enable spaces in directory 
names.

Comment 19

[racham]

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

Comment 20

[Grace Bush]

timeless - please confirm
on win2000-  build 2000082208, I am able to use both command line options and 
create profiles -no crash- no splash screen
on WinNT, the splash screen displays a few seconds but no crash

leaving for you to verify

Comment 21

[timeless]

Verify!! w2k adv svr, using terminal services as a mortal, connecting to 
readonly share. No crash, profile created, logo was shown.

mozilla win32 talkback build 2000082208