asserts when running Viewer




19 years ago
19 years ago


(Reporter: karnaze, Assigned: dougt)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+])



19 years ago
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

19 years ago
=> dougt
Assignee: warren → dougt
Target Milestone: M15

Comment 2

19 years ago
This is not a nsFileSpec related problem.  The nsViewerApp::Initialize is 
requesting pref information too soon:


fails because:


is returning false.

This should be assigned to a profile/preferences guru.
Assignee: dougt → selmer

Comment 3

19 years ago
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

Comment 4

19 years ago
figuring out where the prefs live is part of nsSpecialSystemDirectory.  This 
code was added by the preferences owners. is the owner 
according to owners.html.
Assignee: dougt → neeti

Comment 5

19 years ago
We are getting the assert, because viewer does not use profiles, and 
fails because:

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?

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?


Comment 6

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

Comment 7

19 years ago
Reassigning to dougt for commenting off the assertion in 
Assignee: neeti → dougt

Comment 8

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

Comment 9

19 years ago
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

19 years ago
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.


19 years ago
Keywords: beta1

Comment 11

19 years ago
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

Comment 12

19 years ago
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

19 years ago
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

19 years ago
Putting on PDT+ radar...remove it!
Whiteboard: [PDT+]

Comment 15

19 years ago
fixed checked in.
Last Resolved: 19 years ago
Resolution: --- → FIXED


19 years ago

Comment 16

19 years ago
I will take your word on this that the asserts have been removed.  Marking 
You need to log in before you can comment on or make changes to this bug.