bzr crashed with AttributeError in iter_entries_by_dir() during fast-export
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar Fast Import |
Fix Released
|
Medium
|
Jelmer Vernooij | ||
bzr-fastimport (Ubuntu) |
Fix Released
|
Medium
|
Jelmer Vernooij |
Bug Description
Binary package hint: bzr-fastimport
This crash happens during a fast-export of a small repository, with nothing fancy as far as I know.
ProblemType: Crash
DistroRelease: Ubuntu 10.10
Package: bzr 2.2.0-1
ProcVersionSign
Uname: Linux 2.6.35-19-generic x86_64
Architecture: amd64
BzrDebugFlags: set()
BzrVersion: 2.2.0
CheckboxSubmission: 3be438dd131cd5b
CheckboxSystem: 4ed15c40009aa6f
CommandLine: ['/usr/bin/bzr', 'fast-export', '--plain', 'pool-work', 'foo']
CrashDb: bzr
Date: Mon Sep 6 23:38:08 2010
ExecutablePath: /usr/bin/bzr
FileSystemEncoding: UTF-8
InterpreterPath: /usr/bin/python2.6
Locale: sv_SE.UTF-8
Platform: Linux-2.
ProcCmdline: /usr/bin/python /usr/bin/bzr fast-export --plain pool-work foo
ProcEnviron:
LANGUAGE=sv:en
PATH=(custom, user)
LANG=sv_SE.UTF-8
SHELL=/bin/zsh
PythonVersion: 2.6.6
SourcePackage: bzr
Title: bzr crashed with AttributeError in iter_entries_
UserEncoding: UTF-8
UserGroups: admin pulse pulse-access video
tags: | removed: need-duplicate-check |
tags: | added: patch |
Changed in bzr-fastimport (Ubuntu): | |
status: | New → Triaged |
Changed in bzr-fastimport: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in bzr-fastimport (Ubuntu): | |
importance: | Undecided → Medium |
Changed in bzr-fastimport: | |
status: | Triaged → Fix Committed |
assignee: | nobody → Jelmer Vernooij (jelmer) |
milestone: | none → 0.11.0 |
Changed in bzr-fastimport: | |
status: | Fix Committed → Fix Released |
Changed in bzr-fastimport (Ubuntu): | |
assignee: | nobody → Jelmer Vernooij (jelmer) |
status: | Triaged → In Progress |
The problem seems to be caused by a file that is renamed into a directory. I don't know how this rename ended up in the repository, but according to Jelmer it is a valid operation.
I made a small patch that appears to solve this problem for me, but I don't know if it might break in other cases. The patch stops fast-export from trying to rename all children of a file (which has no children).