I'm getting the following assert when running Viewer. It doesn't happen when running mozilla. usr50 exists. This affects regressin tests which are automated. NTDLL! DbgBreakPoint@0 address 0x77f76148 nsDebug::Break(const char * 0x0139e7c4 ??_C@_0CH@ILML@?4?4?2?4?4?2?4?4?2dist?2include?2nsIFileLoc@, int 64) line 215 nsDebug::Assertion(const char * 0x0139e780 ??_C@_0CI@CIEM@ERROR?3?5File?5locator?5cannot?5locat@, const char * 0x0139e7b0 ??_C@_0BB@DKFO@NS_SUCCEEDED?$CIrv?$CJ?$AA@, const char * 0x0139e7c4 ??_C@_0CH@ILML@?4?4?2?4?4?2?4?4?2dist?2include?2nsIFileLoc@, int 64) line 189 + 13 bytes NS_LocateFileOrDirectory(unsigned int 66539) line 64 + 36 bytes nsPref::useDefaultPrefFile() line 183 + 10 bytes nsPref::ReadUserPrefs(nsPref * const 0x00cb1be0) line 276 + 8 bytes nsViewerApp::Initialize(nsViewerApp * const 0x00c799a0, int 1, char * * 0x00c01870) line 397 main(int 1, char * * 0x00c01870) line 157 mainCRTStartup() line 338 + 17 bytes
Assignee: warren → dougt
Target Milestone: M15
This is not a nsFileSpec related problem. The nsViewerApp::Initialize is requesting pref information too soon: NS_LocateFileOrDirectory(nsSpecialFileSpec::App_PreferencesFile50); fails because: IsCurrentProfileAvailable() is returning false. This should be assigned to a profile/preferences guru.
Assignee: dougt → selmer
Doug, I think the problem is in Viewer not using profiles. Profile manager is forced to return false in this situation. This design was chosen because Viewer is not supposed to have dependencies on profiles. All the prefs are supposed to come from the default prefs. Not knowing much detail about this, it seems like your routine needs to handle the return of false differently since it's a valid return both in Viewer and while we're starting up mozilla and haven't finished profile manager yet. If I'm missing some part of the picture, let me know.
Assignee: selmer → dougt
figuring out where the prefs live is part of nsSpecialSystemDirectory. This code was added by the preferences owners. email@example.com is the owner according to owners.html.
Assignee: dougt → neeti
We are getting the assert, because viewer does not use profiles, and NS_LocateFileOrDirectory(nsSpecialFileSpec::App_PreferencesFile50); fails because: IsCurrentProfileAvailable() is returning false. This is valid because profiles are not created for viewer. This assertion could stop if viewer uses profiles. Chris, do we want to use profiles in viewer? Doug, Another solution would be to comment off the assertion for now and replace it with a printf statement, as a quick fix for this problem. What are the consequences of this? Neeti
As long as nsPref::useDefaultPrefFile() and other calls do error checking. Do you want to fix this?
Reassigning to dougt for commenting off the assertion in NS_LocateFileOrDirectory()
Assignee: neeti → dougt
*** Bug 27076 has been marked as a duplicate of this bug. ***
Adding other Viewer users to CC list who may have opinions. I can think of one reason that Viewer should use profiles. Often I want two different versions of Viewer running to compare their layout. With different profiles I could do that on the same machine. However, if profiles add a lot of extra overhead, we probably don't want them.
Here is what I think: We should find the fastest/sleaziest way to get viewer you off the asserts. If it meant turning it off, sure. Let us do that.
I feel that there will be quite a lot of situations where clients of the layout engine will have no need for profiles. If this is so, then perhaps the asserts can be removed, or turned into diagnostic messages, or moved somewhere else? I currently get about 3-4 asserts from the ActiveX control when it starts and a couple more each time I navigate somewhere.
Target Milestone: M15 → M16
I'm somewhat dubious of the multiple profile usage. The app does nothing to protect its "shared" resources if you manage to create multiple processes accessing things like the registry. Bad things will happen sometimes. The overhead of profiles themselves is probably not much, but ensuring that every other part of the app is using them properly may lead to headaches since viewer hasn't been doing that up to now. I tend to agree with making the asserts just go away unless there's a real bug underneath them.
This seems to have gotten off-track. The problem is that the assert is bogus. Asserting that a file exists is a mistake, especially since the routine returns null when the file cannot be found. Asserts validate a contract, and there is no reason the NS_LocateFileOrDirectory method should require the caller to provide a valid filespec when the routine itself is checking for it. We should remove the assert and get on with our lives.
Putting on PDT+ radar...remove it!
fixed checked in.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
I will take your word on this that the asserts have been removed. Marking verified.
You need to log in before you can comment on or make changes to this bug.