bugGNU nano - Bugs: bug #47135, saving position history cannot...

 
 

bug #47135: saving position history cannot handle more than 8 digits

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Sat 13 Feb 2016 04:04:45 PM UTC  
 
Severity: 3 - NormalStatus: Fixed
Assigned to: Benno Schulenberg <bens>Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 14 Feb 2016 03:35:43 PM UTC, comment #3:

Ehm... I of course meant an 8 MB MP3.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 13 Feb 2016 05:06:15 PM UTC, comment #2:

Fixed in SVN, r5639. (I've been even more generous: giving a possible 20 positions per number.)

How did I find this bug? I foolishly read in an 8 GB MP3 file into the README file... :)

(Of course I exited without saving, but still nano stored the last cursor position, which... in fact doesn't seem right.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 13 Feb 2016 04:30:56 PM UTC, comment #1:

Well, the sizeof() function says how many bytes a type takes up; it does not says how many positions a number can take up when printed out decimally, as the save_poshistory() does.

So... here the maximum long seems to be 2147483647, which is ten positions. If a file has that many lines, it is at least 2 GB, and more likely something like 50 or 80 GB, for which nano is totally useless. So let's just take a fixed 10 postions per number, that is 20 for line and column, plus two spaces, plus a \0 -- 23 characters in total, besides the length of the file name.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 13 Feb 2016 04:04:45 PM UTC, original submission:

To reproduce, first run 'src/nano README', press <Down> and ^X. Now run 'src/nano --ignore ~/.nano/filepos_history', press M-/ and change the numbers after README to "9999 12345", save and exit.

Now run 'MALLOC_CHECK_=2 src/nano NEWS' and press ^X to exit. Result: Aborted.

When the combined number of digits of line number and column number is bigger than eight, save_poshistory() does something wrong.

Valgrind says:

==6177== Invalid read of size 1
==6177== at 0x804DE2A: save_poshistory (files.c:3183)
==6177== by 0x8056BC1: finish (nano.c:625)
==6177== by 0x8056C76: do_exit (nano.c:1150)
==6177== by 0x8057C48: do_input (nano.c:1724)
==6177== by 0x8058790: main (nano.c:2680)
==6177== Address 0x485bb5a is 0 bytes after a block of size 50 alloc'd
==6177== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==6177== by 0x8061192: nmalloc (utils.c:388)
==6177== by 0x804DDE6: save_poshistory (files.c:3180)
==6177== by 0x8056BC1: finish (nano.c:625)
==6177== by 0x8056C76: do_exit (nano.c:1150)
==6177== by 0x8057C48: do_input (nano.c:1724)
==6177== by 0x8058790: main (nano.c:2680)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bens (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 27 Feb 2016 03:08:48 PM UTCbensOpen/ClosedOpen=>Closed
    Sat 13 Feb 2016 05:06:15 PM UTCbensStatusIn Progress=>Fixed
    Sat 13 Feb 2016 04:30:56 PM UTCbensStatusNone=>In Progress
      Assigned toNone=>bens

    Back to the top


    Powered by Savane 3.1-cleanup1