Closed Bug 194066 Opened 21 years ago Closed 8 years ago

assert in nsProfile::SetCurrentProfile during profile switch

Categories

(Core Graveyard :: Profile: BackEnd, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE
mozilla1.4beta

People

(Reporter: NancySumner1, Assigned: ccarlen)

Details

(Keywords: assertion, topembed+, Whiteboard: edt_a3, edt_x3)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: trunk

During a profile switch, an assert is generated in nsProfile::SetCurrentProfile,
line 1262 of nsProfile.cpp.  Looks like DefineLocaleDefaultsDir is returning a
failure code.  The error is coming from the the end of
nsProfile::DefineLocaleDefaultsDir, where directoryService->Set is called - it
returns a failure code because NS_APP_PROFILE_DEFAULTS_50_DIR is already set. 
If this assert is not really a sign of a problem, can the assert be removed, or
the code be changed to handle the failure case?  The assert causes noise that
may make it harder to notice the ones we need to worry about.  :-) 

(This can be seen in mfcembed.)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
-> Conrad
Assignee: adamlock → ccarlen
-> profile mgr backend.

BTW, I think this caused it:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/profile/src&command=DIFF_FRAMESET&file=nsProfile.cpp&rev2=1.263&rev1=1.262
For some reason, the Undefine() was taken out (?!)
Status: UNCONFIRMED → NEW
Component: Embedding: APIs → Profile Manager BackEnd
Ever confirmed: true
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla1.4beta
This bit of conversation from bug 162114:

------- Additional Comment #25 From Doug T 2002-08-15 15:38 -------

if we add undefine, the question is: do you need to undefine before setting
something that already exists.  

------- Additional Comment #26 From Alec Flett 2002-08-15 15:49 -------

nope! undefine is just there as a way to explictly remove an item - it just
seems counter intuitive to me to use set() to un-set something :) - there are
complex interfaces where yet-another-method seems like overkill, but this
interface is pretty darn simple and so I think its worth keeping.

Seems completely the opposite to what is implemented:

738 NS_IMETHODIMP
739 nsDirectoryService::Set(const char* prop, nsISupports* value)
740 {
741     nsCStringKey key(prop);
742     if (mHashtable->Exists(&key) || value == nsnull)
743         return NS_ERROR_FAILURE;

And is the reason replacing Undefine/Define with Set is failing here.  
Keywords: assertion
Keywords: topembed
Discussed in EDT and plussed.
Keywords: topembedtopembed+
Whiteboard: edt_a3
Whiteboard: edt_a3 → edt_a3, edt_x3
QA Contact: carosendahl → profile-manager-backend
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.