bugGNU nano - Bugs: bug #52948, option 'trimblanks' crashes after...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #52948: option 'trimblanks' crashes after inserting a <Space> caused hard-wrapping

Submitter:  Andreas Schamanek <aschamanek>
Submitted:  Mon 22 Jan 2018 12:57:24 PM UTC
   
 
Severity:  5 - Blocker Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Tue 30 Jan 2018 09:53:47 AM UTC, comment #6: 

Fix has been released in 2.9.3.  Thanks again for cathing and reporting it.

Benno Schulenberg <bens>
Group administrator
Wed 24 Jan 2018 08:17:47 PM UTC, comment #5: 

Hi Benno!

I have compiled https://alpha.gnu.org/gnu/nano/nano-2.9.3-pre1.tar.gz and cannot reproduce the original bug and what you described in comment #3.

Thanks a lot!

Andreas Schamanek <aschamanek>
Tue 23 Jan 2018 12:13:28 PM UTC, comment #4: 

Fixed in git, for all types of whitespace, commit 91073be4.

Benno Schulenberg <bens>
Group administrator
Tue 23 Jan 2018 12:00:47 PM UTC, comment #3: 

The fix is not good enough.  It leaves a trailing space when the <Space> was typed before an existing space.  To see what I mean, do:

   printf "aaa\x20\x20\x20bbb" >abba
   src/nano  --fill=10  +1,5  abba

Then type M-P to switch on visible whitespace.  Then type: x <Space>.  This makes the "bbb" wrap to the next line, and the one space before it is trimmed, but not the second space (the one under the cursor), this one stays.  This is not what one would expect.  Expected behavior: when hard-wrapping occurs, and between the cursor and end-of-line there is only whitespace, then all of this whitespace is trimmed -- after the insertion point no whitespace remains.

I can make a simple fix by specifying (old_x - 1), which would work for tabs and spaces, but it would not work for more exotic whitespace.

Benno Schulenberg <bens>
Group administrator
Mon 22 Jan 2018 08:53:34 PM UTC, comment #2: 

Thanks for reporting.  And thanks for testing.  Attached is the patch as I have it sitting in a branch.

(file #43031)

Benno Schulenberg <bens>
Group administrator
Mon 22 Jan 2018 01:11:01 PM UTC, comment #1: 

The verbatim/code block in the original submission initially shows only 60 characters of the text. Below 2 shorter lines will produce the same test.txt:


printf "1234567890123456789012345678901234567890" >test.txt
printf "123456789012345 1234567890123\n" >>test.txt



Andreas Schamanek <aschamanek>
Mon 22 Jan 2018 12:57:24 PM UTC, original submission:  

As mentioned in Segfaults in libc-2.19 w/ 2.9.2 we found a bug in nano 2.9.2 related to trimblanks.

To reproduce, create a file test.txt with

echo "1234567890123456789012345678901234567890123456789012345 1234567890123" >test.txt

I.e., 1 line of 55chars, 1 space and another 13 non-space chars.
Start nano with nano --fill=72 +1,56 test.txt.
Then type:  abc <Space> de
Result: Segmentation fault.

As Benno wrote:

> Note that when you type the <Space>, the cursor does not advance.
> That is obviously wrong.  Apparently the "trimblanks" eats the space
> that you have just typed.  The typed "d" then disappears into the
> void, and the "e" then is too much and crashes the program.


I can confirm that Benno's provided patch avoids the crash.

Andreas Schamanek <aschamanek>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Updated the item)
  • -email is unavailable- added by aschamanek (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-30 bens Open/ClosedOpen Closed
    2018-01-23 bens StatusIn Progress Fixed
    2018-01-22 bens Attached File- Added 0001-wrapping-don-t-trim-a-blank-character-that-the-user-.patch, #43031
        Severity3 - Normal 5 - Blocker
        StatusNone In Progress
        Assigned toNone bens
        Summarytrimblanks crash when wrapping option 'trimblanks' crashes after inserting a <Space> caused hard-wrapping

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code