300122 - Crash [@ ConvertUnicharToUCS4]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Bastiaan Jacques]

This crash is triggered by testcases 3 and 4 in bug 252970. However, that bug
has been declared a windows-only problem and the stacktrace is different, so
I've started a new bug.

This crash seems to originate in nsTextFrame::GetPointFromOffset(), which
sometimes calls nsRenderingContextGTK::GetWidth() with an invalid aLength
parameter, as you can see in frame 5 in the stacktrace.

Comment 1

[Bastiaan Jacques]

Attachment: gdb stacktrace

Comment 2

[Bastiaan Jacques]

Attachment: prevents the crash

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsTextFrame.cpp&mark=4193,4213#4180


The problem is that ip[inOffset] contains a rather large number, which causes
ConvertUnicharToUCS4() to overflow the buffer. The attached patch checks for
that and corrects if necessary.

The next step is to determine _why_ ip[inOffset] contains such a large number.

Comment 3

[Jungshik Shin]

 Some thunderbird stack traces (mentioned in bug 252970)  go through
GetPointFromOffset so that it may prevent TB from crashing.

Comment 4

[rbs]

re: gdb stacktrace

#4  nsRenderingContextGTK::GetWidth (... aLength=142683648 ...)
#5  nsTextFrame::GetPointFromOffset (... inOffset=1 )

It all looks very fishy. How can a simple inOffset=1 lead to such a huge length.
It is not even that inOffset is big (implying that some other code/loop kicks in
and messes things up). It gives the impression that no code (or little code) is
reached, leaving things uninitialized by the time we get there.

Comment 5

[Andrew Schultz]

I get a lot of UMRs with valgrind starting with:
Conditional jump or move depends on uninitialised value(s)
 nsTextFrame::PrepareUnicodeText(nsTextTransformer&, nsAutoIndexBuffer*,
nsAutoTextBuffer*, int*, int, int*) (nsTextFrame.cpp:1900)
 nsTextFrame::GetPointFromOffset(nsPresContext*, nsIRenderingContext*, int,
nsPoint*) (nsTextFrame.cpp:4171)
 nsTypedSelection::GetPointFromOffset(nsIFrame*, int, nsPoint*)
(nsSelection.cpp:6734)
 nsTypedSelection::GetCachedFrameOffset(nsIFrame*, int, nsPoint&)
(nsSelection.cpp:5086)

nsTextFrame.cpp:1900 is
   if ((ip[mContentLength] - mContentOffset) < textLength) {
ip[mContentLength] was the uninitialized part.

Comment 6

[Andrew Schultz]

I forgot to mention this sems to be gtk1-only.  And nightly builds seem immune
to the crash.

Comment 7

[Bastiaan Jacques]

This occurs in my gtk2 build.

Comment 8

[Bastiaan Jacques]

The fixes for bug 252970 seem to have fixed this bug as well. If you can
reproduce the crash and you're seeing the stacktrace in attachment 188693 [details],
please reopen.

Comment 9

[Adam Guthrie]

*** Bug 312782 has been marked as a duplicate of this bug. ***

Comment 10

[Adam Guthrie]

Reopening based on the stack in bug 312782.

Comment 11

[rbs]

This is probably not happening again on the trunk and RC1 - because they have
the fix from bug 307875 which protects against such crashes once for all.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Adam, generally, same or similar stack does not necessarily mean same bug, esp.
if the testcases in one bug are fixed...

Comment 13

[Adam Guthrie]

Sorry for the trouble. I should have verified this myself in the latest builds
before reopening.