Error in/around InsertNewLine

[erwilliams]

Using WinXP SP3, I've been able to reproduce this using the main branch as well as adamv and joeri's forks. I've yet to go back and see if this occurs on a fresh 1.0.32 install.

Procedure: I begin by editing a php file (I assume it works with other languages). Then, I type an if statement or a for statement and hit return. I'm guessing this is where the problems begin as I would assume the new line should be indented and it is not. Now, if I type an open bracket, the line indents, the open and close brackets are created, and the cursor is set between them. Everything is copacetic so far... ...right up until I hit enter. That's when everything blows up.

When not debugging, I get an error on FixedLine.cpp(241) which I think is (238) on the main branch. In either case, it's this line: wxASSERT(!text.empty() && m_extsBuf.size() == text.size());

When debugging, I get a bit more information. e.exe!FixedLine::SetLine(unsigned int startpos=69, unsigned int endpos=73, bool cache=true) Line 251 + 0x12 bytes C++ e.exe!Lines::SetLine(unsigned int lineId=9) Line 53 + 0x5b bytes C++ e.exe!Lines::SetCaretPos(bool update=false) Line 246 C++ e.exe!Lines::SetPos(unsigned int newpos=71, bool update_lastpos=true) Line 173 C++ e.exe!EditorCtrl::InsertNewline() Line 2142 C++ e.exe!EditorCtrl::InsertChar(const wchar_t & text=L'') Line 2175 C++ e.exe!EditorCtrl::OnChar(wxKeyEvent & event={...}) Line 6591 C++

Apologies if that gets horribly formatted. I'm new to github.

If I move the cursor outside of the brackets, then move it back and hit enter there is no problem. Additionally there are other combination that have the same effect.

[erwilliams]

Ok, so that formatting was easier than expected. Here are the sequences I've tried and their results. | indicated cursor position. // Original example if (something) {|} // was auto-indented here Enter => Error

if (something) {|}
Enter => Error

// # = any character
if (something) {#|}
Enter =>
if (something) {#
    |
}

if (something) {|}
if (something) {}|    // Move cursor anywhere
if (something) {|}    // Move cursor back
Enter =>
if (something) {
    |
}

[adamv]

Just tried this on my build; typed the first two lines of the original example above, then pressing '{' gave me an assert within the binary-only core library.

The last line I have source for is Document.cpp, line 310 "m_textData.GetTextPart() in Document::TextPart."

[astigsen]

Could you try this with the latest master (build with wxwidgets 2.8.10)? I don't seem to be able to reproduce it here.

Are you writing the PHP code within a HTML document (with HTML as the selected syntax)?

[peol]

I'm still crashing, built on Vista x64 with wxWidgets 2.8.10. It crashes in any programming language bundle (I'm using JavaScript), if (something) {} still crashes, deleting the right one and adding it again and pressing works. It only seems to be when it is autocompleting the curly braces.

[peol]

My |ENTER| tags disappeared (I guess it thought it was an HTML element, silly me). "[...] if (something) {|ENTER|}" "[...] adding it again and pressing |ENTER| works"

[adamv]

Entering this on XP3 (32) w/ 2.8.10 still crashes e. New document, select PHP: // Original example if (something) {

On typing the { I get an assertion failure.

[astigsen]

Weird, I am still not able to reproduce it (I am on Vista (32)).

@adamv: Did the assert in the core library give any output?

[peol]

I had it working for a second yesterday, but now I'm back with crashes again. It doesn't seem to be curly bracers only though, in at least JavaScript [] also breaks e with the same error message.

[astigsen]

Could you give me the exact text of the error message? I would really like to track this down, but as I can't reproduce it on my setup, I will need as much info as possible from those of you who experience it.

[adamv]

c:\dev\ecore\cdatatext.cpp(90): assert "utf8_len(buffer[b] == len - b" failed in cDataText::GetTextPart().

call stack: ... [06] Document::GetTextPart document.cpp:310 Styler_Syntax::DoSearch styler_syntax:464 Styler_Syntax::Insert styler_syntax:955 EditorCtrl::StylersInsert editorctrl.cpp:2860 and some more lines up through [20] GetDC.

[adamv]

http://www.flickr.com/photos/adamvandenberg/3531770585/

[astigsen]

The assert indicates that the range of text requested by GetTextPart ends in the middle of an uncomplete utf-8 sequence. Since there is nothing above the ascii range in the sample, it seems like some garbage memory is at some point above getting written into the document. This could also be why I can't reproduce is (it may depend on memory layout).

It would be very helpful if you could step through EditorCtrl::InsertChar before the assert happens, and see what gets inserted. The problem seems to be associated with indentation changes, so it might be useful to keep an eye on the variable m_indent (which contains the current indentation unit).

Could you also tell me what your current indentation settings are?

[peol]

I leave the debugging to adamv, I don't know what the hell I'm doing. :-) I actually thought about the indentation earlier, I'm using a custom "two spaces represents tab" and the document encoding's I'm using varies between ISO-8859-1 and UTF-8 (mainly UTF-8 though)

[adamv]

I'm set to Soft Tabs, 4, default (Windows 1252), CRLF

[adamv]

(Also, I have to set the new document to PHP before typing, or it doesn't repro.)

On line 2264 there's a doc.Insert(linestart=35, indent=string containing 4 spaces) This returns an indent_len of 4 Line 2266: m_lines.Insert(linestart=35, indent_len=4) Then I step into EditorCtrl::StylersInsert

Inside Styler_Syntax::Insert(pos=35, length=4) docLen = 41

Get down to Styler_Syntax:DoSearch(start=35, end=41, limit=41) Line 463, doc.GetTextPart(si.lineStart=35, si.lineEnd=42, si.line=empty vector

Get into Document::GetTextPart. Calls m_textData.GetTextPart(start_pos=35, end_pos=41, buffptr = resized to 6 characters)

At that point I don't have source code, and the assertion happens.

[astigsen]

Thanks to those of you who sent me further info. I have located the problem, and it is a bug in the metakit library. I should have a fix out shortly.

[peol]

Awesome, looking forward to try it out!

[astigsen]

Fixed bug in metakit that garbled insertions. Closed by 2d0178bda7d438af02c487c46e01e84e9db6f527