Closed Bug 280351 Opened 20 years ago Closed 20 years ago

Startup asserts in nsLocalFileUnix

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: bzbarsky, Assigned: Biesinger)

References

(Blocks 1 open bug)

Details

(Keywords: assertion)

Attachments

(1 file, 1 obsolete file)

The checkin for bug 276588 causes assertions on startup: ###!!! ASSERTION: Relative paths not allowed: 'Error', file /home/bzbarsky/mozilla/debug/mozilla/xpcom/io/nsLocalFileUnix.cpp, line 287 I just ran 'firefox http://whatever' I don't see a reasonable component for this in the toolkit product, so picking something semi-randomly.
-> xpcom... we should just remove the assertion, imo
Component: XRE Startup → XPCOM
Product: Toolkit → Core
Version: unspecified → Trunk
*** Bug 282653 has been marked as a duplicate of this bug. ***
Attached patch remove the assertion (obsolete) (deleted) — Splinter Review
trying to init a localfile with something that may or may not be an absolute path is not a bug - the caller may do this to check whether it is and handle failure gracefully.
Assignee: benjamin → cbiesinger
Status: NEW → ASSIGNED
Attachment #174685 - Flags: superreview?(darin)
Attachment #174685 - Flags: review?(dougt)
Target Milestone: --- → mozilla1.8beta2
Comment on attachment 174685 [details] [diff] [review] remove the assertion according to the idl, rel paths are an error. http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsILocalFile.idl#76 It seams like this would be a bandaide to a problem higher up in the command parsing food chain.
Attachment #174685 - Flags: review?(dougt) → review-
Comment on attachment 174685 [details] [diff] [review] remove the assertion Doug, I know that they are an error, and I am relying on that fact. Why can't it happily throw the exception without asserting?
Attachment #174685 - Flags: review- → review?(dougt)
Comment on attachment 174685 [details] [diff] [review] remove the assertion >Index: nsLocalFileUnix.cpp >=================================================================== >RCS file: /cvsroot/mozilla/xpcom/io/nsLocalFileUnix.cpp,v >retrieving revision 1.121 >diff -p -u -6 -r1.121 nsLocalFileUnix.cpp >--- nsLocalFileUnix.cpp 30 Jan 2005 08:55:16 -0000 1.121 >+++ nsLocalFileUnix.cpp 18 Feb 2005 15:11:50 -0000 >@@ -282,13 +282,12 @@ nsLocalFile::InitWithNativePath(const ns > NS_FAILED(homeDir->GetNativePath(homePath))) { > return NS_ERROR_FAILURE; > } > > mPath = homePath + Substring(filePath, 1, filePath.Length() - 1); > } else if (filePath.IsEmpty() || filePath.First() != '/') { >- NS_ERROR("Relative paths not allowed"); > return NS_ERROR_FILE_UNRECOGNIZED_PATH; > } else { > mPath = filePath; > } else after return is a non-sequitur. How about } else { if (filePath.IsEmpty() || filePath.First() != '/') return NS_ERROR_FILE_UNRECOGNIZED_PATH; mPath = filePath; } This also fixes the 2 vs. 4 space indentation. /be
Comment on attachment 174685 [details] [diff] [review] remove the assertion sure. i don't really care if you assert or not.
Attachment #174685 - Flags: review?(dougt) → review+
Comment on attachment 174685 [details] [diff] [review] remove the assertion sr=darin with brendan's version
Attachment #174685 - Flags: superreview?(darin) → superreview+
Attached patch final patch (deleted) — Splinter Review
Attachment #174685 - Attachment is obsolete: true
Checking in xpcom/io/nsLocalFileUnix.cpp; /cvsroot/mozilla/xpcom/io/nsLocalFileUnix.cpp,v <-- nsLocalFileUnix.cpp new revision: 1.122; previous revision: 1.121 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: