42449 - crash on delete of initial text in textarea

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Clone V. Barkins]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000612
BuildID:    2000061208

When filling out the Bugzilla helper form, I tried to delete the numbers of the
steps in the textarea under the section "Steps to Reproduce".  As soon as I hit
delete, Mozilla crashed and caused a page fault.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.mozilla.org/quality/help/bug-form.html
2. Scroll to section entitled "Steps to Reproduce"
3. Highlight the numbers already there and hit delete.

Actual Results:  Mozilla crashed and caused a page fault.



Expected Results:  Mozilla should have either deleted the selection or ignored
the attempt to delete it.

Here is the output of the crash report:

MOZILLA caused an invalid page fault in
module GKHTML.DLL at 015f:601d6689.
Registers:
EAX=00000000 CS=015f EIP=601d6689 EFLGS=00010202
EBX=00000000 SS=0167 ESP=0068e6a4 EBP=0068ed5c
ECX=00000002 DS=0167 ESI=00000000 FS=4317
EDX=40004424 ES=0167 EDI=0a5a710c GS=0000
Bytes at CS:EIP:
80 7c 08 ff 0a 75 73 ff 4d fc eb 6e 8d 45 fc 8d
Stack dump:
00000000 0a5a710c 00000000 00000000 00000000 00000000 0aa180a0 00000000 0068e6cc
00000100 00000000 00000000 00960640 0a59aca4 008f4c04 0a59adac

Comment 1

[Jeffrey Baker]

Confirmed on Linux with build 061314 (M17).  Making bug new, adding crash
keyword, and changing opsys/platform.

Comment 2

[rods (gone)]

reassigning

Comment 3

[rubydoo123]

setting to m17 with the other backspace/crash bugs

Comment 4

[rubydoo123]

updated priority and severity

Comment 5

[Andreas Franke (gone)]

This crash still occurs on PC/Linux, build 2000071208, as opposed to bug 42888
which is works-for-me now.

Comment 6

[Andreas Franke (gone)]

Attachment: stack trace on Linux 7/1

Comment 7

[Andreas Franke (gone)]

The crash happens in mozilla/layout/html/base/src/nsTextFrame.cpp, line 2507.

A debug build shows that frag->Get1b() returns 0x0, causing text being null,
and then we crash trying to access text[textLength - 1] with textLength begin 2.

     } else {
        text = frag->Get1b() + mContentOffset;
        textLength = mContentLength;

        // See if we should skip leading whitespace
        if (0 != (mState & TEXT_SKIP_LEADING_WS)) {
          while ((textLength > 0) && XP_IS_SPACE(*text)) {
            text++;
            textLength--;
          }
        }

        // See if the text ends in a newline
2507    if ((textLength > 0) && (text[textLength - 1] == '\n')) {
          textLength--;
        }
        NS_ASSERTION(textLength >= 0, "bad text length");
      }

Get1b() is defined in mozilla/layout/base/public/nsTextFragment.h

Comment 8

[Andreas Franke (gone)]

To be honest, I have not seen frag->Get1b() returning null _before_ the crash,
it's just a guess. I only know that text is null at the point where the crash
happens, and "(gdb) print frag->Get1b()" says it would give null then as well.   

Comment 9

[anthonyd]

I am having a great deal of difficulty reproducing this.  I got a crash to 
happen once, but that was INSERTING text after i deleted it, and I have since 
not been able to reproduce that either.  Any help in establishing a better test 
case for this would be appreciated.

Anthony

Comment 10

[rubydoo123]

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

Comment 11

[Andreas Franke (gone)]

This stopped crashing at some point between 2000071408 and 2000071609.

Comment 12

[anthonyd]

this bug was fixed by ender-lite changes.

Comment 13

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- MacOS9 2000-07-18-10-M17 Commercial
- Linux6 2000-07-19-10-M17 Commercial
- Win98  2000-07-19-11-M17 Commercial