26691 - asserts when running Viewer

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[karnaze (gone)]

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

Comment 1

[Warren Harris]

=> dougt

Comment 2

[Doug Turner (:dougt)]

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.

Comment 3

[selmer (gone)]

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.

Comment 4

[Doug Turner (:dougt)]

figuring out where the prefs live is part of nsSpecialSystemDirectory.  This 
code was added by the preferences owners. [e-mail] is the owner 
according to owners.html.

Comment 5

[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

Comment 6

[Doug Turner (:dougt)]

As long as nsPref::useDefaultPrefFile() and other calls do error checking.  Do 
you want to fix this?

Comment 7

[neeti]

Reassigning to dougt for commenting off the assertion in 
NS_LocateFileOrDirectory()

Comment 8

[Doug Turner (:dougt)]

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

Comment 9

[karnaze (gone)]

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.

Comment 10

[Suresh Duddi (gone)]

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.

Comment 11

[locka]

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.

Comment 12

[selmer (gone)]

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.

Comment 13

[Marc Attinasi]

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.

Comment 14

[leger]

Putting on PDT+ radar...remove it!

Comment 15

[Doug Turner (:dougt)]

fixed checked in.

Comment 16

[Tom Everingham]

I will take your word on this that the asserts have been removed.  Marking 
verified.