#95 Continuous wrap updating bugs

release
closed-fixed
Eddy De Greef
Program (402)
5
2002-02-07
2001-11-25
Eddy De Greef
No

Bug report submitted via discuss mailing list
by Randal Koene:

Hi there,

Replacing selected text causes program to segfault.
Continuous line wrapping produces erroneous <nl>
(newline) codes.

These bugs occur only for very specific files. The
file must be an HTML file and it must have a single
line. The bug was not replicated for longer HTML
texts. It was also not replicated for plain text. I
did not test all language modes. The bug occurs with
pre-existing files, not with HTML text typed into a
new window.

The bug does *not* appear with NEdit installed
without a personalized .nedit file. With my existing
.nedit (used previously with nedit-5.1) file, the
bug *does* occur. Some further testing shows that
the bug occurs only with my (highly customized)
.nedit when default text fonts are set to the
following:
nedit.textFont:
-adobe-courier-bold-r-normal--12-120-75-75-m-70-iso8859-1
nedit.boldHighlightFont:
-adobe-courier-bold-r-normal--14-*-*-*-*-*-*-*
nedit.italicHighlightFont:
-adobe-courier-bold-i-normal--12-120-75-75-m-0-iso8859-1
nedit.boldItalicHighlightFont:
-adobe-courier-bold-o-normal--14-*-*-*-*-*-*-*

It does not occur, if bold, italic and bolditalic
fonts are assigned with the "fill from primary"
button in the default text fonts selection widget.
If I set the fonts accordingly in an uncustomized
.nedit file no bug occurs. For the purpose of
replication I have included the problematic .nedit
file as an attachment to this email.

A good example is the following:

bash$ echo '<P>' > somefile.html
bash$ nedit somefile.html

Then select ALL the text in the file and press
backspace. At that point the program should
disappear. A segmentation fault is produced.

Note: The bug can be avoided by performing the
backspace erasure of the text in the following way:
(1) switch the language mode to "plain"
(2) select and erase the text

This is *not* restricted to erasure with backspace.
Selecting all the text with the mouse and then
pressing a key (e.g. space) to replace it, or using
the cut keys (ctrl+x) causes the same crash. The
same is true if the text is selected by choosing
"select all" from the edit menu.

The second bug, which occurs when continuous line
wrapping mode is on and editing an existing file
such that the cursor nears the end of the line, also
appears to be caused by the font settings. For the
purpose of replication, I have also included a short
HTML text as an attachment, for which the bug
occurs. Open the text with nedit (using the .nedit
file supplied). Go to the end of the line that reads
"incurred if the phase relationship is not
present.". Then type on. Once you near the border of
the window, the next line should change to
"</CODE><nl><UL>", where <nl> is a non-printable
character representing a newline. If you type
another character at that point, all text below the
cursor location is erased. This looks like another
bounds checking problem that could lead to a
segmentation fault. Again, it is related to the use
of the default fonts in the customized .nedit file.

The version of NEdit is 5.2, installed from the
binary distribution file nedit-5.2-linux-x86.tar.Z
with file size 1268195 bytes and checksum (cksum)
3276223212, as obtained from the www.nedit.org site.

Discussion

  • Eddy De Greef
    Eddy De Greef
    2001-11-25

    .nedit file causing the problem

     
    Attachments
  • Eddy De Greef
    Eddy De Greef
    2001-11-25

    • assigned_to: nobody --> edg
     
  • Eddy De Greef
    Eddy De Greef
    2001-11-25

    Html file showing the second bug

     
    Attachments
  • Eddy De Greef
    Eddy De Greef
    2001-11-25

    Logged In: YES
    user_id=73597

    The cause of both bugs is the same: when a buffer is
    modified, the text display widget tries to calculate the
    affected region. This goes fine in almost all cases,
    except one: when countinous wrap is used in combination
    with variable font widths (eg, bold font is larger than
    normal font, or proportional fonts), the calculation needs
    the style information as it existed _before_ the
    modification, but that is no longer available. The updated
    style information is used instead, possibly leading to
    wrong calculations and/or crashes eventually.

    I would call this a design bug, and there's no easy way
    to work around it. I've literally spent days trying to find
    a simple solution, but I always got stuck somewhere.
    Eventually I came up with the (huge) patch that is attached:
    it performs part of the necassary calculations before the
    buffer is modified, and part of them afterwards. This is
    only done when necessary, to reuse the more efficient
    implementation in non-problematic cases.

    Conceptually, it is the right thing to do, I believe,
    but I am a bit hesitating to apply it to cvs without a
    second opinion. But since this stuff is so hard to
    understand, I don't think I will get a second opinion ...

     
  • Eddy De Greef
    Eddy De Greef
    2001-11-25

    • status: open --> open-fixed
     
  • Eddy De Greef
    Eddy De Greef
    2001-11-25

    bugfix patch

     
  • Eddy De Greef
    Eddy De Greef
    2002-02-03

    Logged In: YES
    user_id=73597

    I've committed the patches.

     
  • Eddy De Greef
    Eddy De Greef
    2002-02-03

    Logged In: YES
    user_id=73597

    I've committed the patches.

     
  • Eddy De Greef
    Eddy De Greef
    2002-02-07

    • status: open-fixed --> closed-fixed
     
  • Eddy De Greef
    Eddy De Greef
    2002-02-07

    Logged In: YES
    user_id=73597

    The fix appears to be fine (and is also required for
    bug #510631), so I'm closing this.