Closed
Bug 191529
Opened 22 years ago
Closed 22 years ago
nsGlyphTable::ElementAt misuses nsDependentCString
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: rbs, Assigned: rbs)
References
()
Details
Attachments
(3 files)
(deleted),
patch
|
dbaron
:
review-
dbaron
:
superreview-
dbaron
:
approval1.3b-
|
Details | Diff | Splinter Review |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
dbaron
:
approval1.3b+
|
Details | Diff | Splinter Review |
Something weird is happening with nsDependent[C]String. With a recent build, the
test URL renders incorrectly. But with Nav7.0 or with the patch that I am going
to attach, it renders correctly.
The patch reverts a line added as part of bug 164575.
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsMathMLChar.cpp&root=/cvsroot&subdir=mozilla/layout/mathml/base/src&command=DIFF_FRAMESET&rev1=1.79&rev2=1.80
I wonder it this isn't bitting other people. I am correcting the MathML one
after much debugging in the stretching code (hunting elusive problems elsewhere
without suspecting that it was this one).
Comment on attachment 113267 [details] [diff] [review]
patch
putting this simple one-liner in the r/sr/a queues.
nsDependentCString is holding on to outdated data, causing unexpected behavior.
Attachment #113267 -
Flags: superreview?(roc+moz)
Attachment #113267 -
Flags: review?(roc+moz)
Attachment #113267 -
Flags: approval1.3b?
Comment 3•22 years ago
|
||
that seems surprising... that data shouldn't be 'outdated' - buf should be
remaining in scope.
what platform is this on?
what exactly do you think is the bug here?
Comment 4•22 years ago
|
||
There's a for loop here, and buf is used later in the loop, so it can be
modified during the lifetime of the string:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/mathml/base/src/nsMathMLChar.cpp&rev=1.84&mark=411-412,427,438,449#408
nsDependentCString is supposed to be dependent on the buffer you give it --
that's the point. If you modify that buffer, you modify what's in the string.
And not only that, the string will then be confused about its own length.
Summary: nsDependent[C]String is buggy → nsGlyphTable::ElementAt misuses nsDependentCString
Comment 5•22 years ago
|
||
Comment on attachment 113267 [details] [diff] [review]
patch
I think a better fix would be to use a separate buffer instead of reusing cbuf.
Comment 7•22 years ago
|
||
Attachment #113267 -
Flags: superreview?(roc+moz)
Attachment #113267 -
Flags: superreview-
Attachment #113267 -
Flags: review?(roc+moz)
Attachment #113267 -
Flags: review-
Attachment #113267 -
Flags: approval1.3b?
Attachment #113267 -
Flags: approval1.3b-
fix string usage, and in the process, make the code more resistant to
subsequent string-fu.
Comment 9•22 years ago
|
||
Comment on attachment 113364 [details] [diff] [review]
patch v2 - use separate buffers
Using PR_snprintf in the case where you already have the key seems a little
excessive (although somewhat parallel to the section below), but otherwise this
looks fine. r+sr=dbaron
Attachment #113364 -
Flags: superreview+
Attachment #113364 -
Flags: review+
Assignee | ||
Comment 10•22 years ago
|
||
Comment on attachment 113364 [details] [diff] [review]
patch v2 - use separate buffers
-> putting in the drivers queue for 1.3b.
The patch fixes a bad string usage that causes unexpected behavior.
Attachment #113364 -
Flags: approval1.3b?
Updated•22 years ago
|
Attachment #113364 -
Flags: approval1.3b? → approval1.3b+
Assignee | ||
Comment 12•22 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•4 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•