Closed
Bug 194066
Opened 22 years ago
Closed 9 years ago
assert in nsProfile::SetCurrentProfile during profile switch
Categories
(Core Graveyard :: Profile: BackEnd, defect)
Core Graveyard
Profile: BackEnd
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.
Assignee | ||
Comment 2•22 years ago
|
||
-> 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
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla1.4beta
Comment 3•22 years ago
|
||
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
Updated•22 years ago
|
Whiteboard: edt_a3
Updated•21 years ago
|
Whiteboard: edt_a3 → edt_a3, edt_x3
Updated•15 years ago
|
QA Contact: carosendahl → profile-manager-backend
Blocks: 1243899
Comment 5•9 years ago
|
||
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.
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•