Closed Bug 245053 Opened 20 years ago Closed 20 years ago

Profilemanager crashes when you try to delete a profile

Categories

(Toolkit :: Startup and Profile System, defect, P2)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.7.4

People

(Reporter: ehume, Assigned: benjamin)

References

Details

(Keywords: crash, fixed-aviary1.0)

Attachments

(1 file)

profile delete patch fix
687 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040529 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040529 Firefox/0.8.0+

When starting the new Ffx builds (I have to do it three times, but you knew
that), if the flag -profilemanager is used, the new Profile Manager is invoked.
If you try to delete a profile, the profilemanager crashes. After that, even
three tries does not revive Ffx. I have to clean out all the directories and
start over.


Reproducible: Always
Steps to Reproduce:
1. Start Firefox with a shortcut or line command that includes "...firefox.exe"
-profilemanager
2. When Profile Manager comes up, select Delete Profile. This will often produce
the crash.
3. If asked whether or not to delete the files, choose Yes.

Actual Results:  
Profile Manager crashed

Expected Results:  
Profile should have been deleted.

When one has generated several profiles, you can click on the next to last
profile in the list of profiles, but not the last profile. Earlier you could
click on the next to last profile and use the arrow key to get down to the last
one. Not now.
I could have sworn ben already turned this off for Firefox, but he might not
have checked this in.  In any case, I see the same thing, this probably needs to
morph to a Tbird bug though.
Assignee: firefox → bsmedberg
Status: UNCONFIRMED → NEW
Component: General → Startup and Profile System
Ever confirmed: true
QA Contact: firefox.general → bsmedberg
"...turned this off for Firefox." ??? You're not going to get rid of the Profile
Manager? I need that. If the new one doesn't work, bring back the old one. It
worked fine.
you can still access multiple profiles via the command line.  This was something
that was supposed to be done around Phoenix 0.1 time, but for some reason never
happened until now-ish.
Severity: normal → major
Keywords: crash
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040603 Firefox/0.8.0+

This latest nightly also brings up the profile manager GUI when trying to
customise the location of the profile. Following deletion of the 'profiles'
directory - but not the profiles.ini and registry.dat - the profile manager
starts and allows a profile to be added.

Trying to delete the existing profile will cause a crash, but starting again
will use the newly created profile. 

I would rather it doing this than having to go back to the command line - that'd
be so 1990's.......
1990's or not, having a command line -- or a command in the shortcut -- allows
us to use more than one profile. When the command line/shortcut option works,
you can have shortcuts that open different profiles. Not an option now.
> 1990's or not, having a command line -- or a command in the shortcut -- allows
> us to use more than one profile. When the command line/shortcut option works,
> you can have shortcuts that open different profiles. Not an option now.

Huh? firefox -P <profilename> has worked from the commandline for years, and it
still works. So does firefox -createprofile <profilename>

Let's keep this bug focused: it's about the crash when you delete a profile from
the profilemanager UI. I would appreciate crash backtraces... I'm having trouble
reproducing it meaningfully and getting a debugger attached.

*** Bug 245759 has been marked as a duplicate of this bug. ***
From bug 245759:

0x0806beeb in nsToolkitProfile::Remove (this=0x85fd018, removeFiles=0)
    at
/home/shaver/mozilla/mozilla/toolkit/profile/src/nsToolkitProfileService.cpp:239
239         nsToolkitProfileService::gService->mDirty = PR_TRUE;
(gdb) p nsToolkitProfileService::gService
$1 = (nsToolkitProfileService *) 0x0
(gdb)

We're being called from JS above.  Started firefox with -ProfileManager, this is
my only profile.
Flags: blocking1.0+
*** Bug 245788 has been marked as a duplicate of this bug. ***
Severity: major → critical
Using the 0.9RC on WinXP.
The crash only occurs on deleting a profile with a relative path (IsRelative=1
in profiles.ini).
It happens wheter you choose to delete files or not. If you choose to delete
them, they are deleted before the crash happens. But the profile isn't removed
from profiles.ini. So the crash happens in between.

Hope that helps to isolate the issue.
Flags: blocking0.9?
Summary: Profilemanager crashes when you try to delete a profile. → Profilemanager crashes when you try to delete a profile with a relative path
State Dump for Thread Id 0x3c0

eax=00000000 ebx=01855d0a ecx=00239678 edx=0089d448 esi=00239670 edi=0012e3b0
eip=00406aba esp=0012e1dc ebp=0012e1f0 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000246


function: NSCanUnload
        00406a9a 83660c00         and    dword ptr [esi+0xc],0x0
ds:00d23556=????????
        00406a9e 6a00             push    0x0
        00406aa0 8bcf             mov     ecx,edi
        00406aa2 ff1570ce8900                                   
ds:0089ce70=602fcfd5
                                  call  dword ptr [jpeg_fdct_ifast+0xaccc
(0089ce70)]
        00406aa8 a1982aa300                                     
ds:00a32a98=00000000
                                  mov  eax,[nsColorNames::kColors+0x741a0
(00a32a98)]
        00406aad 5f               pop     edi
        00406aae 397010           cmp     [eax+0x10],esi        
ds:00ae9ee6=9d68016e
        00406ab1 7507             jnz     NS_RegistryGetFactory+0x799 (00409dba)
        00406ab3 33c0             xor     eax,eax
        00406ab5 a3982aa300                                     
ds:00a32a98=00000000
                                  mov  [nsColorNames::kColors+0x741a0
(00a32a98)],eax
FAULT ->00406aba c7401c01000000   mov   dword ptr [eax+0x1c],0x1
ds:00ae9ee6=9d68016e
        00406ac1 33c0             xor     eax,eax
        00406ac3 5e               pop     esi
        00406ac4 c20800           ret     0x8
        00406ac7 55               push    ebp
        00406ac8 8bec             mov     ebp,esp
        00406aca 56               push    esi
        00406acb 8b7508           mov     esi,[ebp+0x8]         
ss:00c180d6=????????
        00406ace 8b4624           mov     eax,[esi+0x24]        
ds:00d23556=????????
        00406ad1 85c0             test    eax,eax
        00406ad3 740f             jz      NS_RegistryGetFactory+0x5fc3 (0040f5e4)
        00406ad5 8b4d0c           mov     ecx,[ebp+0xc]         
ss:00c180d6=????????
Note: this was when deleting a profile with IsRelative=0.
Removing the "relative path" from the summary again.
I just deleted %appdata%\Firefox and removed that profile from
%appdata%\Mozilla\Firefox\profiles.ini. All my profiles are now in
%appdata%\mozilla\firefox\profiles.
Now deleting a profile does no longer crash.
Summary: Profilemanager crashes when you try to delete a profile with a relative path → Profilemanager crashes when you try to delete a profile
Flags: blocking0.9? → blocking0.9-
Priority: -- → P2
Target Milestone: --- → Firefox1.0beta
This bug also appears in Thunderbird.
cc'ing myself as this crash effects Thundbird as well. I'll release note it for 0.7.
It ends up deleting the profile but not deleting it's existance from the
profile.ini file.  Manually deleting the entry in profile.ini solves the problem
Hope this helps:
I tested this by creating a profile in a test folder on my desktop. When I chose
to delete the profile (including files), not only will all files within the
folder be deleted (including ones not created by Firefox), but the folder itself
is also deleted.

Creating a profile does not create a folder, but deleting a profile does delete
the folder.
I have tried a number of experiments with 0.9 profiles:

If I inspect profiles.ini the path to MY OLD profile has an .slt
folder.  If I create  a new profile in a folder, the process is all
screwed up:  I created one at PATH =D:\Scratch with name Default User.

1.  The path in profiles.ini was D:\Scratch  it should have been
D:\Scratch\Default User
2.   For sure, there was no salted file
3.  I created one using the default path with name "test" .  It showed
up as  Path=Profiles/test  (Note the forward slash)  The test file is
not salted.

Here is what profiles.ini looked like with all three profiles:

[General]
StartWithLastProfile=1

[Profile0]
Name=Firefox
IsRelative=0
Path=D:\Profiles\Firefox\p2uzdja5.slt

[Profile1]
Name=Default User
IsRelative=0
Path=D:\Scratch
Default=1

[Profile2]
Name=test
IsRelative=1
Path=Profiles/test

When I tried to delete the middle one and clicked on "Don't delete
files" Profile Manager crashed.  In a previous run, it also crashed when
I clicked on "Delete Files"
> I have tried a number of experiments with 0.9 profiles:

These are all mostly-unrelated to the crash here.

> 1.  The path in profiles.ini was D:\Scratch  it should have been
> D:\Scratch\Default User
> 2.   For sure, there was no salted file

This is by design. If you want the profile in D:\Scratch\Default User then you
must choose that path specifically. We do not salt profiles except for the
"default" profile, because non-default profiles are already pretty much immune
from phishing attacks.

For *this bug*... could somebody who experiences this run with a debug build and
turn on trace-refcnt logging for nsToolkitProfileService? I suspect that I'm
over-releasing the service, but I couldn't find where in a basic code audit.

Uh, I ran into this a few minutes ago.. this patch fixes it for me (looks like
a typo), unless I'm missing something?
(In reply to comment #19)

> This is by design. If you want the profile in D:\Scratch\Default User then you
> must choose that path specifically. We do not salt profiles except for the
> "default" profile, because non-default profiles are already pretty much immune
> from phishing attacks.
 
Then the Create profile User Interface should eliminate the top box to avoid
confusion.   
patch checked-in on trunk and branch (we don't actually build this code yet on
the trunk)

idgreenwald: you're totally off-topic... if you want to suggest changes to the
folder handling in the "create profile" dialog, do so in bug 247218.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Thanks, vladimir! Can you test a nightly build tomorrow and mark this bug
VERIFIED if the crash is fixed?
QA Contact: bsmedberg → vladimir
*** Bug 247539 has been marked as a duplicate of this bug. ***
Works fine now with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040618 Firefox/0.9.0+ (Steffen). -> v.
Status: RESOLVED → VERIFIED
Still get the crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040618 Firefox/0.9 (MOOX-AV)
Still get the crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040618 Firefox/0.9 (MOOX-AV)

And what's this "verified fixed"?
*** Bug 247757 has been marked as a duplicate of this bug. ***
(In reply to comment #27)
> Still get the crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
> Gecko/20040618 Firefox/0.9 (MOOX-AV)
> 
> And what's this "verified fixed"?

Is or isn't this one fixed? Are we allowed to uncheck "verify fixed"? If so,
maybe you should do this.
This still occurs, with both relative and non-relative profiles, in firefox
0.9.1 on linux.  However, it does not occur in my CVS build, and lxr shows that
the patch went in on 06/07, well before 0.9.  My backtrace is not useful, but
I'm pretty sure we shouldn't be talking to nsPrintSession here:

(gdb) where
#0  0x0877c320 in nsPrintSession::QueryInterface ()
#1  0x550f0fa7 in XPTC_InvokeByIndex () from ./libxpcom.so
#2  0x080917b9 in ?? ()
#3  0x089d0c18 in ?? ()
#4  0x00000006 in ?? ()
#5  0x00000001 in ?? ()
#6  0xfeffcc3c in ?? ()
#7  0x0807d1f1 in ?? ()
#8  0xfeffcb44 in ?? ()
#9  0x08a0f9cc in ?? ()
#10 0x0aa06048 in ?? ()
#11 0x00000000 in ?? ()

Reopening this, though I can't explain why it's crashing in the release builds..
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 249002 has been marked as a duplicate of this bug. ***
A cvs diff -r FIREFOX_0_9_1_RELEASE nsToolkitProfileService.cpp shows that the
version of the file that went in was from May 25, even though the patch went in
after that; the patch for this did not make it into 0.9.1.  Is there a sticky
tag set somewhere?
No longer blocks: 249002
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040702
Firefox/0.9.0+, I created and deleted profiles with relative and user-defined
addresses. In both cases, I experienced no crashes.

I believe this has been true since soon after the 0.9 build was released, at
least for my installation of Win XP.
Checkin to the aviary branch:
2004-06-17 10:02 (file rev. 1.1.2.2.2.7).
This was after Firefox 0.9 was released. 0.9 is still affected by this bug.

Checkin to the trunk:
2004-06-17 10:05 (file rev. 1.3).

Checkin to the FIREFOX_0_9_1_branch:
Not at all! 0.9.1 is still affected by this bug.
The 0.9.1 branch is based on the 0.9 release. It only includes half a dozen
fixes and a theme update, but not the bulk of the checkins to the aviary branch
after the 0.9 release.

cvs graph (see bsmedberg's checkins from 17-Jun-2004):
http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/toolkit/profile/src/nsToolkitProfileService.cpp

Comment 26 and 27 is about a 0.9.1 build, see the "0.9" in the build id.
Comment 30 is about 0.9.1.
So there are no reports with current aviary or trunk builds. Marking as fixed again.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
*** Bug 250378 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
> Checkin to the aviary branch:
> 2004-06-17 10:02 (file rev. 1.1.2.2.2.7).
> This was after Firefox 0.9 was released. 0.9 is still affected by this bug.
> 
> Checkin to the trunk:
> 2004-06-17 10:05 (file rev. 1.3).
> 
> Checkin to the FIREFOX_0_9_1_branch:
> Not at all! 0.9.1 is still affected by this bug.
> The 0.9.1 branch is based on the 0.9 release. It only includes half a dozen
> fixes and a theme update, but not the bulk of the checkins to the aviary branch
> after the 0.9 release.
> 
> cvs graph (see bsmedberg's checkins from 17-Jun-2004):
>
http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/toolkit/profile/src/nsToolkitProfileService.cpp
> 
> Comment 26 and 27 is about a 0.9.1 build, see the "0.9" in the build id.
> Comment 30 is about 0.9.1.
> So there are no reports with current aviary or trunk builds. Marking as fixed
again.



Does this now need to go into 0.9.2?
There's nothing to do here. 0.9.2 is still basically 0.9 plus half a dozen
fixes. This one is not among them.

Current nightlies (branch and trunk) are fixed, and so will 1.0 and its
pre-release/release candidate builds. Get one of these, there's enough to test:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/
0.9.2 is gone, I don't anticipate we'll have a 0.9.3 unless something unforeseen
happens
Status: RESOLVED → VERIFIED
*** Bug 250512 has been marked as a duplicate of this bug. ***
*** Bug 251744 has been marked as a duplicate of this bug. ***
*** Bug 252429 has been marked as a duplicate of this bug. ***
Keywords: fixed-aviary1.0
*** Bug 256225 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: