328606 - Crash after entering <smiley><space><space>

Status: RESOLVED FIXED

(Core :: Spelling checker, defect)

Description

[John Ellson]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.1) Gecko/20060223 Fedora/1.5.0.1-5 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.1) Gecko/20060223 Fedora/1.5.0.1-5 Firefox/1.5.0.1

I reported this in Fedora BZ #178274 but nobody seems interested in looking at it.

On x86_64, but not i386, entering a smiley from the smiley menu, then two space
characters crashes thunderbird.

thunderbird-1.5-3.x86_64.rpm



Reproducible: Always

Steps to Reproduce:
1.thunderbird
2.File->New->Message
3.click on message body to move focus
4.smiley_menu->Smile
5.<space><space>

Actual Results:  
cursor doesn't move for spaces
crash

Expected Results:  
normal text entry after smileys

Comment 1

[timeless]

we certainly don't support their rpms. build from source (specify which branch you're using or trunk - for consistency, there's nothing wrong w/ using the thundebird1.5 sourceball if you can find it) w/ --enable-debug --disable-optimize --disable-strip

(commands written for some random shell, if your shell is different, fix.)

run

export MOZ_NO_REMOTE=1
export NO_EM_RESTART=1
./run-mozilla.sh -g -d gdb ./thunderbird-bin
r
where
list
info locals
info threads

http://www.mozilla.org/unix/debugging-faq.html

Comment 2

[John Ellson]

I tried building from thunderbird-1.5-source.tar.bz2 but make dies with:

rm -f libmozjs.so
gcc  -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_ellson -DTRACING -g -fno-inline -fPIC -shared -Wl,-h -Wl,libmozjs.so -o libmozjs.so  jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o              -lm -ldl -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm
/usr/bin/ld: jsapi.o: relocation R_X86_64_PC32 against `memset@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
gmake[3]: *** [libmozjs.so] Error 1
gmake[3]: Leaving directory `/home/ellson/FIX/Linux.x86_64/build/mozilla/js/src'gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/home/ellson/FIX/Linux.x86_64/build/mozilla/js'
gmake[1]: *** [tier_2] Error 2
gmake[1]: Leaving directory `/home/ellson/FIX/Linux.x86_64/build/mozilla'
make: *** [default] Error 2

Comment 3

[timeless]

add
ac_cv_visibility_pragma=no
to your mozconfig and rebuild the world

note that this indicates your build toolchain is broken, unfortunately, that's normal for x86_64.

Comment 4

[John Ellson]

Bug is reproducible with vanilla thunderbird-1.5-source.tar.bz2

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47279260816176 (LWP 25034)]
0x00002b00142f1e00 in nsString::CharAt (this=0x7fffffa95d60, i=4294967295)
    at ../../../dist/include/string/nsTString.h:134
134               return mData[i];
(gdb) list
129              */
130
131           char_type CharAt( index_type i ) const
132             {
133               NS_ASSERTION(i <= mLength, "index exceeds allowable range");
134               return mData[i];
135             }
136
137           char_type operator[]( index_type i ) const
138             {
(gdb) where
#0  0x00002b00142f1e00 in nsString::CharAt (this=0x7fffffa95d60, i=4294967295)
    at ../../../dist/include/string/nsTString.h:134
#1  0x00002b00142f1e23 in nsString::operator[] (this=0x7fffffa95d60,
    i=4294967295) at ../../../dist/include/string/nsTString.h:139
#2  0x00002b00142ea9ee in mozInlineSpellChecker::EndOfAWord (this=0x1016820,
    aNode=0x1532138, aOffset=-1) at mozInlineSpellChecker.cpp:980
#3  0x00002b00142ed151 in mozInlineSpellChecker::AdjustSpellHighlighting (
    this=0x1016820, aNode=0x1532138, aOffset=-1,
    aSpellCheckSelection=0x1041f30, isDeletion=0)
    at mozInlineSpellChecker.cpp:848
#4  0x00002b00142ed822 in mozInlineSpellChecker::SpellCheckAfterEditorChange (
    this=0x1016820, action=1001, aSelection=0x1041aa0,
    previousSelectedNode=0x1532138, previousSelectedOffset=0,
    aStartNode=0x1532138, aStartOffset=0, aEndNode=0x1532138, aEndOffset=1)
    at mozInlineSpellChecker.cpp:261
#5  0x00002b0015b1d9bf in nsEditor::HandleInlineSpellCheck (this=0x103de30,
    action=1001, aSelection=0x1041aa0, previousSelectedNode=0x1532138,
    previousSelectedOffset=0, aStartNode=0x1532138, aStartOffset=0,
    aEndNode=0x1532138, aEndOffset=1) at nsEditor.cpp:5399
#6  0x00002b0015aceaba in nsHTMLEditRules::AfterEditInner (this=0xfce8c0,
    action=1001, aDirection=1) at nsHTMLEditRules.cpp:547
#7  0x00002b0015acec36 in nsHTMLEditRules::AfterEdit (this=0xfce8c0,
    action=1001, aDirection=1) at nsHTMLEditRules.cpp:391
---Type <return> to continue, or q <return> to quit---

Comment 5

[timeless]

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp&rev=1.9&mark=911,922,1030,1043#859

Thank you very much. signed offsets and -1s, wonderful. unfortunately I don't understand this code and doesn't include explanations of what it's thinking. so i'm assigning it to bienvenu to clean up.

Comment 6

[David :Bienvenu]

When I try this on windows, I get an offset of -1, but we bail out here:

  rv = GenerateRangeForSurroundingWord(currentNode, aOffset, getter_AddRefs(wordRange));

  // if we don't have a word range to examine, then bail out early.
  if (!wordRange)
    return NS_OK;


because wordRange is null. Thus, we don't get to the crashing code.

Comment 7

[David :Bienvenu]

Attachment: possible fix

I think this should fix it, but I don't know why we're not crashing on windows...can you try this patch out, John, if you're able to build?

Comment 8

[John Ellson]

It doesn't crash with the patch, but the spaces still don't show up.

Instead of:  <smiley><space><space>words
I get:       <smiley>words

Comment 9

[David :Bienvenu]

my recollection is that's not related to inline spell-checking...did you try turning it off?

Comment 10

[John Ellson]

Which, the crash or the missing spaces?

I turned off inline spell checking and the spaces still don't appear.
Do you want me to take out the patch as well?

Comment 11

[David :Bienvenu]

I'm saying the missing spaces is a separate bug, and is an editor bug, not related to inline spell-checking (and is already filed, I'm pretty sure)

Comment 12

[Adam Guthrie]

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

Comment 13

[juan becerra [:juanb]]

I can see this problem in Thunderbird 2.0.0.0. When you compose a message and add a smiley, you cannot type spaces immediatly after the smiley.