Version: 551787 (using KDE Devel) Installed from: Compiled sources Compiler: gcc (GCC) 4.1.0 (SUSE Linux) OS: Linux Kate crashes, if you try to insert a new line after the 'else' keyword in the attached C code file.
Created attachment 16644 [details] C source
You have to save it locally with cpp extension.
Using host libthread_db library "/lib64/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 47215474321504 (LWP 3542)] [KCrash handler] #5 0x000000000040afc8 in QChar (this=0x7fff7936ffb0, c=@0x2005e870e) at /usr/local/lib64/qt3/include/qstring.h:270 #6 0x00002af136f28436 in KateTextLine::stringAtPos (this=0xe675f0, pos=4294967295, match=@0x7fff79370090) at /home/kde/3.5/kdelibs/kate/part/katetextline.cpp:191 #7 0x00002af136f7f274 in KateCSmartIndent::calcContinue (this=0x641bf0, start=@0x7fff79370260, end=@0x7fff79370640) at /home/kde/3.5/kdelibs/kate/part/kateautoindent.cpp:894 #8 0x00002af136f801cc in KateCSmartIndent::calcIndent (this=0x641bf0, begin=@0x7fff79370640, needContinue=true) at /home/kde/3.5/kdelibs/kate/part/kateautoindent.cpp:778 #9 0x00002af136f8088e in KateCSmartIndent::processNewline (this=0x641bf0, begin=@0x7fff79370640, needContinue=true) at /home/kde/3.5/kdelibs/kate/part/kateautoindent.cpp:595 #10 0x00002af136efa230 in KateDocument::newLine (this=0x7918a0, c=@0x7fff793706a0, v=0xc2deb0) at /home/kde/3.5/kdelibs/kate/part/katedocument.cpp:3001 #11 0x00002af136f5c026 in KateViewInternal::doReturn (this=0xc2deb0) at /home/kde/3.5/kdelibs/kate/part/kateviewinternal.cpp:898 #12 0x00002af136f3826c in KateView::keyReturn (this=0xc2a2b0) at /home/kde/3.5/kdelibs/kate/part/kateview.h:325 #13 0x00002af136f57b8d in KateViewInternal::keyPressEvent (this=0xc2deb0, e=0x7fff79371240) at /home/kde/3.5/kdelibs/kate/part/kateviewinternal.cpp:2477
Created attachment 16728 [details] check result of nextNonBlankChar for -1 Can you please test whether this patch fixes the crash for you? The bug does not lead to a crash on 32bit platforms. Since I don't have 64bit hardware, I cannot verify it.
*** This bug has been marked as a duplicate of 129580 ***
The patch in #4 fixes it.
The fix in 129580 does NOT fix this issue. The patch in #4 does.
Hi Johannes, why does it only happen on 64 bit and not on 32 bit? Please enlighten me :)
*** Bug 129506 has been marked as a duplicate of this bug. ***
Dominik, If nextNonSpaceChar() does not find any non-space chars, it returns -1, which turns into 2^32-1 when it is passed to stringAtPos(), which takes an unit. Now, in this line in KateTextLine::stringAtPos(): if (unicode[i+pos] != matchUnicode[i]) when i is still 0, i+pos becomes 2^32-1 due to then unsigned-ness of pos. On a 64bit environment, an address that is 4GB away is addressed, which likely is not mapped. SIGSEGV. On 32bit hardware, this wraps around and addresses the QChar at unicode-1. This is still a bug, but it normally does not crash, because that address is available (malloc's administrative data).
> On a 64bit environment, an address that is 4GB away is addressed, which > likely is not mapped. SIGSEGV. On 32bit hardware, this wraps around and > addresses the QChar at unicode-1. This is still a bug, but it normally does > not crash, because that address is available (malloc's administrative data). Thanks for the info. Patch is ok, I cannot test it on 64 bit, though. You should apply it ;)
SVN commit 553727 by jsixt: Fix an off-by-1 (32bit) resp. off-by-2^32-1 (64bit) access by catching -1 before it is passed to stringAtPos(). BUG: 129263 M +3 -2 kateautoindent.cpp --- branches/KDE/3.5/kdelibs/kate/part/kateautoindent.cpp #553726:553727 @@ -891,9 +891,10 @@ { cur.setCol(cur.col() + 4); needsBalanced = false; - if (textLine->stringAtPos(textLine->nextNonSpaceChar(cur.col()), "if")) + int next = textLine->nextNonSpaceChar(cur.col()); + if (next >= 0 && textLine->stringAtPos(next, "if")) { - cur.setCol(textLine->nextNonSpaceChar(cur.col()) + 2); + cur.setCol(next + 2); needsBalanced = true; } }
Just for info: also fixed in trunk, as we changed the parameter from uint to int.
*** Bug 130085 has been marked as a duplicate of this bug. ***