Closed Bug 333318 Opened 14 years ago Closed 13 years ago

nsChromeRegistry::GetProviderAndPath might pass -1 to nsTAString_CharT::Assign as length

Categories

(Toolkit :: Startup and Profile System, defect)

PowerPC
macOS
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: timeless, Assigned: Gijs)

References

(Blocks 1 open bug, )

Details

(Keywords: coverity)

Attachments

(1 file)

found by coverity
Attached patch PatchSplinter Review
So, would this do? I think so, but shouldn't this method fail if there's no path and only a provider?
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #260220 - Flags: first-review?(benjamin)
Comment on attachment 260220 [details] [diff] [review]
Patch

Do we know how this could be tickled? I'd like a testcase if at all possible.
Attachment #260220 - Flags: first-review?(benjamin) → first-review+
So just running:

Components.classes["@mozilla.org/io/io-service;1"].getService(Components.interfaces.nsIIOService).newURI("chrome://foo/con", null, null);

Will trigger this code - except it seems that nsTAString_CharT::Assign doesn't really give a ... if you pass it -1 for length. This is because nsTSubstring tests for -1 explicitly. See:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/string/src/nsTSubstring.cpp&rev=1.24&mark=335-336#325


(execution path for that one-liner to the bug marked by coverity is roughly:

ioservice :: newURI
chrome protocol handler :: newURI
chrome service :: Canonify
chrome service :: GetProviderAndPath
)

Marking this INVALID, since it's not really a bug. Please reopen if you think I'm wrong (which altogether isn't all that unlikely in this area of the code).
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
er, that's obviously supposed to be @mozilla.org/network/io-service;1
Oops. Sorry for bugspam.
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in before you can comment on or make changes to this bug.