Closed Bug 191529 Opened 22 years ago Closed 22 years ago

nsGlyphTable::ElementAt misuses nsDependentCString

Categories

(Core :: XPCOM, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: rbs, Assigned: rbs)

References

()

Details

Attachments

(3 files)

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
Attached patch patch (deleted) — Splinter Review
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?
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?
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 on attachment 113267 [details] [diff] [review] patch I think a better fix would be to use a separate buffer instead of reusing cbuf.
> what exactly do you think is the bug here? see screenshot.
Comment on attachment 113267 [details] [diff] [review] patch Marking review-, etc. See comment 5.
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-
Attached patch patch v2 - use separate buffers (deleted) — Splinter Review
fix string usage, and in the process, make the code more resistant to subsequent string-fu.
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+
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?
-> taking the bug
Assignee: jaggernaut → rbs
Attachment #113364 - Flags: approval1.3b? → approval1.3b+
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: