Lucid: recovery silently deletes data in large files.

Bug #1059085 reported by Adam Buchbinder
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vim (Ubuntu)
Fix Released
High
Unassigned
Lucid
Fix Released
High
Bartosz Kosiorek
Precise
Fix Released
High
Unassigned
Quantal
Fix Released
High
Unassigned
Raring
Fix Released
High
Unassigned

Bug Description

This is present in vim 2:7.2.330-1ubuntu3, in Lucid. It was fixed upstream in 7.3.216, which is in Precise and newer. To replicate the bug (taken from https://groups.google.com/d/topic/vim_use/CNuBWi0763I/discussion):

[Summary]

The recovery process silently deletes part of the file it's run on, when the file is large enough (40,000 lines seems to trigger it).

[Impact]

The recovery process, while it may not recover all of the user's changes since the process was killed, is expected to at least not destroy random chunks of data in the middle of a large file. This bug has bitten me at least twice--silently!--before I found out what was going on.

[Test Case]

1. Run 'vi test.txt'.
2. Type '78a-' [ESC], then 'yy', '39999p', then ':wq', to create a 40,000-line test file.
3. Run 'cp test.txt test.bak'.
4. Run 'vi test.txt'.
5. Type 'Ox' to make a small change to the file.
6. From another terminal window, run 'ps x|grep [t]est.txt' to find the PID of the running vim process.
7. Run 'kill $PID' to terminate the process.
8. Run 'vi test.txt', and type 'r' to attempt recovery, then ':wq' to save the recovered contents.
9. Run 'wc -l test.txt test.bak'.

Expected output:
$ wc -l test.txt test.bak
  40001 test.txt
  40000 test.bak

Actual output:
$ wc -l test.txt test.bak
  38629 test.txt
  40000 test.bak

[Regression Potential]

Small. The patch I'm backporting (https://groups.google.com/d/topic/vim_dev/lTos-bGcNgU/discussion) in is part of the new 7.3 series, and vim has a large test suite; I'm porting and checking the patch as-is, including its tests. If this breaks the recovery process, the regression tests will catch it.

Related branches

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Triaged: Reporter points to discussion and fix
Importance: High (I was wondering about crticial since it's a data loss/corruption, but there again it's in a vi recovery which is reasonably rare and not an arbitrary corruption)

Changed in vim (Ubuntu):
status: New → Triaged
importance: Undecided → High
summary: - recovery silently deletes data in large files.
+ Lucid: recovery silently deletes data in large files.
description: updated
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Looks good, ACK.

Uploading to lucid-proposed for processing by the SRU team.

Thanks!

Changed in vim (Ubuntu Lucid):
status: New → Confirmed
Changed in vim (Ubuntu Precise):
status: New → Fix Released
Changed in vim (Ubuntu Quantal):
status: New → Fix Released
Changed in vim (Ubuntu Raring):
status: Triaged → Fix Released
Changed in vim (Ubuntu Lucid):
importance: Undecided → High
Revision history for this message
Clint Byrum (clint-fewbar) wrote : Please test proposed package

Hello Adam, or anyone else affected,

Accepted vim into lucid-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/vim/2:7.2.330-1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in vim (Ubuntu Lucid):
status: Confirmed → Fix Committed
tags: added: verification-needed
Revision history for this message
Bartosz Kosiorek (gang65) wrote :

Before install package from proposed
$ wc -l test.txt test.bak
  39707 test.txt
  40000 test.bak
  79707 razem

Revision history for this message
Bartosz Kosiorek (gang65) wrote :

And after installl package from proposed.
$ wc -l test.txt test.bak
  40002 test.txt
  40000 test.bak
  80002 razem

Verified on Lucid Lynx

Changed in vim (Ubuntu Lucid):
assignee: nobody → Bartosz Kosiorek (gang65)
Changed in vim (Ubuntu Quantal):
importance: Undecided → High
Changed in vim (Ubuntu Precise):
importance: Undecided → High
tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vim - 2:7.2.330-1ubuntu3.1

---------------
vim (2:7.2.330-1ubuntu3.1) lucid-proposed; urgency=low

  * Backported upstream patch 7.3.216 from
    https://groups.google.com/d/topic/vim_dev/lTos-bGcNgU/discussion
    (LP: #1059085):
    - src/memline.c: Avoid corruption on large-file recovery.
    - src/testdir/test70.in, src/testdir/test70.ok:
      Test large-file recovery.
    - src/testdir/Makefile, src/testdir/Make_amiga.mak,
      src/testdir/Make_dos.mak, src/testdir/Make_os2.mak,
      src/testdir/Make_vms.mms: Update Makefiles to include new tests.
 -- Adam Buchbinder <email address hidden> Sun, 30 Sep 2012 10:44:38 -0400

Changed in vim (Ubuntu Lucid):
status: Fix Committed → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote : Update Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.