bzr crashed with ShortReadvError in _seek_and_read(): readv() read 0 bytes rather than 174 bytes at 0 for "469df00e67f848246f876663fb299e10.rix"

Bug #832052 reported by Vadim Rutkovsky
This bug report is a duplicate of:  Bug #413430: ShortReadvError on index file. Edit Remove
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bzr (Ubuntu)
New
Undecided
Unassigned

Bug Description

crashed during commit operation

ProblemType: Crash
DistroRelease: Ubuntu 11.10
Package: bzr 2.4.0-0ubuntu2
ProcVersionSignature: User Name 3.0.0-9.12-generic 3.0.3
Uname: Linux 3.0.0-9-generic i686
Architecture: i386
BzrDebugFlags: set()
BzrVersion: 2.4.0
CommandLine: ['/usr/bin/bzr', 'commit', '-m', 'Started baobab tests']
CrashDb: bzr
Date: Mon Aug 22 11:55:02 2011
ExecutablePath: /usr/bin/bzr
FileSystemEncoding: UTF-8
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta i386 (20110418)
InterpreterPath: /usr/bin/python2.7
Locale: en_US.UTF-8
PackageArchitecture: all
Platform: Linux-3.0.0-9-generic-i686-with-Ubuntu-11.10-oneiric
ProcCmdline: /usr/bin/python /usr/bin/bzr commit -m Started\ baobab\ tests
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
PythonVersion: 2.7.2
SourcePackage: bzr
Title: bzr crashed with ShortReadvError in _seek_and_read(): readv() read 0 bytes rather than 174 bytes at 0 for "469df00e67f848246f876663fb299e10.rix"
UpgradeStatus: No upgrade log present (probably fresh install)
UserEncoding: UTF-8
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
Vadim Rutkovsky (roignac) wrote :
tags: removed: need-duplicate-check
Julian Taylor (jtaylor)
visibility: private → public
Revision history for this message
Martin Pool (mbp) wrote :

Hi,

This is a dupe of bug 413430 which basically says a file has been truncated - typically this happens because of an OS error or disk error or a machine crash.

In 2.4.0 we started flushing files to disk by default after they're written, which was intended to reduce the frequency of this. So, it's possible this problem was introduced by an earlier client and just discovered by bzr 2.4.0, or perhaps our check is not enough, or perhaps something else.

Do you recall if your machine recently crashed or abruptly stopped or had any similar problem?

(fdatasync is not going to be enough on its own; continued incidents of this mean perhaps we need built in recovery.)

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.