Closed
Bug 479057
Opened 16 years ago
Closed 16 years ago
Prefixing a string to an empty autostring causes an extra pointless copy
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
Tracking | Status | |
---|---|---|
status1.9.1 | --- | .10-fixed |
People
(Reporter: neil, Assigned: neil)
Details
Attachments
(2 files)
984 bytes,
patch
|
Details | Diff | Splinter Review | |
1.60 KB,
patch
|
benjamin
:
review+
beltzner
:
approval1.9.1.10+
|
Details | Diff | Splinter Review |
Steps to reproduce problem:
1. Start a debug build
2. Turn off keyword.enabled
3. Try to load ://
Actual result: ###!!! ASSERTION: buffer incorrectly sized: 'a.Length() == headLen', file nsTSubstringTuple.cpp, line 78
What's happening here is that nsDefaultURIFixup strips off the bogus :// and attempts to prefix http:// in its place. It does this using
uriString.Assign(NS_LITERAL_CSTRING("http://") + uriString);
We create a substring tuple from "http://" and [R]uriString, and decide that [L]uriString doesn't depend on it, so that we can write to it in place. So we adjust [L]uriString's length, and then try to copy [R]uriString and "http://". Of course since [L]uriString and [R]uriString are the same thing, we've just changed [R]uriString's length which is why we get confused as to what to copy.
Assignee | ||
Comment 1•16 years ago
|
||
We actually copy "http://" to uriString, and then uriString to uriString.
Assignee | ||
Comment 2•16 years ago
|
||
This test fails with our current code.
Assignee | ||
Comment 3•16 years ago
|
||
Passes the test :-)
Updated•16 years ago
|
Assignee: neil → nobody
Component: XPCOM → String
QA Contact: xpcom → string
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → neil
Updated•16 years ago
|
Attachment #362917 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 4•16 years ago
|
||
Pushed changeset 6c0ff682551d to mozilla-central.
Actually I pushed it yesterday. See bug 478732 for the gory details.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Attachment #362917 -
Flags: approval1.9.1.10?
Comment 6•15 years ago
|
||
would we not want this on the 1.9.2 branch if it's good for the 1.9.1 branch?
Assignee | ||
Comment 7•15 years ago
|
||
It landed before 1.9.2 branched.
Comment 8•15 years ago
|
||
Comment on attachment 362917 [details] [diff] [review]
Confident patch
a=beltzner for 1.9.1.10
Attachment #362917 -
Flags: approval1.9.1.10? → approval1.9.1.10+
Assignee | ||
Comment 9•15 years ago
|
||
Pushed changeset 9a06693cdbb4 to releases/mozilla-1.9.1
status1.9.1:
--- → .10-fixed
Target Milestone: --- → mozilla1.9.2a1
Updated•4 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•