hg recover doesn't find any uncommitted transactions. I am not able to see commit history. My working copy is ok. hg fetch also works d:\repos>hg log ** unknown exception encountered, details follow ** report bug details to http://mercurial.selenic.com/bts/ ** or mercurial@selenic.com ** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] ** Mercurial Distributed SCM (version 1.6.4) ** Extensions loaded: fixfrozenexts, purge, churn, fetch, progress, color Traceback (most recent call last): File "hg", line 36, in <module> File "mercurial\dispatch.pyo", line 16, in run File "mercurial\dispatch.pyo", line 34, in dispatch File "mercurial\dispatch.pyo", line 54, in _runcatch File "mercurial\dispatch.pyo", line 494, in _dispatch File "mercurial\dispatch.pyo", line 355, in runcommand File "mercurial\extensions.pyo", line 174, in wrap File "hgext\color.pyo", line 211, in colorcmd File "mercurial\dispatch.pyo", line 545, in _runcommand File "mercurial\dispatch.pyo", line 499, in checkargs File "mercurial\dispatch.pyo", line 492, in <lambda> File "mercurial\util.pyo", line 420, in check File "mercurial\commands.pyo", line 2544, in log File "mercurial\cmdutil.pyo", line 1192, in iterate File "mercurial\commands.pyo", line 2542, in prep File "mercurial\cmdutil.pyo", line 714, in show File "mercurial\cmdutil.pyo", line 746, in _show File "mercurial\localrepo.pyo", line 320, in nodetags File "mercurial\localrepo.pyo", line 255, in tags File "mercurial\localrepo.pyo", line 276, in _findtags File "mercurial\tags.pyo", line 29, in findglobaltags File "mercurial\tags.pyo", line 183, in _readtagcache ValueError: invalid literal for int() with base 10: ''
TortoiseHG repository explorer also crashes with this info: {{{ #!python ** Please report this bug to http://bitbucket.org/tortoisehg/stable/issues or tortoisehg-discuss@lists.sourceforge.net ** Mercurial version (1.6.4). TortoiseHg version (1.1.4) ** Command: --nofork log ** CWD: D:\sozluk-2.0 ** Extensions loaded: fixfrozenexts, purge, churn, fetch ** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] ** sys.getwindowsversion(): (6, 1, 7600, 2, '') ** Processor architecture: x64 Traceback (most recent call last): File "tortoisehg\hgtk\hgtk.pyo", line 74, in dispatch File "tortoisehg\hgtk\hgtk.pyo", line 202, in _runcatch File "tortoisehg\hgtk\hgtk.pyo", line 271, in runcommand File "tortoisehg\hgtk\hgtk.pyo", line 322, in _runcommand File "tortoisehg\hgtk\hgtk.pyo", line 276, in checkargs File "tortoisehg\hgtk\hgtk.pyo", line 270, in <lambda> File "mercurial\util.pyo", line 420, in check File "tortoisehg\hgtk\hgtk.pyo", line 434, in log File "tortoisehg\hgtk\hgtk.pyo", line 338, in gtkrun File "tortoisehg\hgtk\gdialog.pyo", line 257, in display File "tortoisehg\hgtk\gdialog.pyo", line 479, in _setup_gtk File "tortoisehg\hgtk\history.pyo", line 344, in get_menu_list File "tortoisehg\util\hglib.pyo", line 158, in getfilteredtags File "mercurial\localrepo.pyo", line 255, in tags File "mercurial\localrepo.pyo", line 276, in _findtags File "mercurial\tags.pyo", line 29, in findglobaltags File "mercurial\tags.pyo", line 183, in _readtagcache ValueError: invalid literal for int() with base 10: '' }}}
What has happened leading up to this error? My guess is some crash that made the tag cache invalid. I guess 'hg verify' doesn't tell you anything useful either?
Yes I experienced multiple blue screens on this machine. Verify doesn't find anything, here is the output: checking changesets checking manifests crosschecking files in changesets and manifests checking files 4066 files, 1747 changesets, 11380 total revisions
Try to remove .hg/tags.cache - or move it elsewhere. It seems like you had a local corruption and no Mercurial bug is involved here.
Yeah that fixed it thanks!
Fixed by http://hg.intevation.org/mercurial/crew/rev/2d754eae430c Nicolas Dumazet <nicdumz.commits@gmail.com> tags: do not fail if tags.cache is corrupted (issue2444)
tags.cache corruption seems to be somewhat common on Windows, but no where else. I don't know if this is virus scanner related or something worse. I've never actually seen it myself.
Strange, considering that we do use atomictemp which guarantees that the whole file has been written and closed before it appears as tags.cache. In what ways are/were tags.cache corrupted? Corrupted, or just truncated?
I've not seen a corrupted file myself, so I can't say. http://bitbucket.org/tortoisehg/stable/issues?q=_readtagcache
The file was 143 bytes long but I didn't get its backup. Not sure if that means truncation or content corruption.
How long is it now when it has been rebuilt? How long is the first tag name in the file (on the 3rd line)?
I did only one checkin afterwards. It's still 143 bytes :) Here are the contents: 1746 348dcbd66151a2234a503280ec274b53c1132927 0f88b86d10e4e73fd215b9c2f8c144d2c4a7bcd0 8720eb9a21ac2700c6437899daea0c587197c7c6 2.0-prototype
Just another data point. I'm running Mac OS X 10.6.4 with hg version 1.6.3+20100826. I have just seen exactly the same problem/backtrace with 'hg log' as ssg first reported. It occurred immediately after a power failure, although I wasn't using hg at the time of loss of power. 'hg verify' reports no problems. Removing the tags.cache fixed the problem - the old(bad) tags.cache file appeared to have binary garbage in it - the new one seems to have something more readable in a text editor (although only 45 bytes long).
Are the corrupted tags.cache completely bogus? Can we get one (and its recovered version)? The consequences of a corrupted tags.cache has been papered over for 1.7, but the real issue here is how it could get corrupted in the first place. The only explanation I can come up with is that the file system changes only had been partially written to the disk before crashing. We use close+rename and are thus guaranteed a consistent view as long as the OS is running, but the (journaling?) file system and hardware might not give the same guarantee in case of hard crashes. Perhaps an append-only file format (like what is used for other storage) would fail less often?
The attached zip file contains the original corrupt tags.cache file in tags.cache.files/corrupt/. (Its contents include my machine's hostname of all things...) The recreated (current) one after I removed the corrupt one is in tags.cache.files/new/. This .hg repository was actually on a mounted encrypted disk image which probably complicates things as there's another whole layer of file system 'stuff'.
I was curious to see if I could reproduce the problem. Couldn't really get exactly the same problem, but in case it's of interest or of help in reproducing similar problems down the track, I was able to get 'hg stat' to issue "abort: working directory has unknown parent '312037646134'!" messages after gracelessly unmounting the disk image (pull out the USB stick suddenly) on which the .hg repository resides. Unless hg can force the disk image system to flush all events properly to disk somehow, it might tough to protect against this kind of problem... Instructions below. The attached Archive.zip contains: - commands.txt # Command-line commands to create repo and corrupt it - commands-transcript.txt # Transcript of above commands and their output - hg-after-removal.tar # .hg before corruption - hg-before-removal.tar # .hg after corruption Steps to reproduce: 1. On Mac OS X, 10.6.4, open /Applications/Utilities/Disk Utility and create a disk image: 1a. File menu -> New -> New Blank image… 1b. Navigate to a removable drive (eg. USB stick) and name the disk image file 'test 1c. 'Name' the disk image 'test' 1d. Change the 'Encryption' to 128-bit 1e. Change the 'Image Format' to 'sparse disk image' 1f. Press the 'Create' button and enter a password 1g. The disk image should be mounted automatically 2. Open /Applications/Utilities/Terminal and enter the commands from commands.txt
Switching this back to resolved - one bug per issue please. I think you'll find there are existing issues for dirstate corruption.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:13 EDT --- This bug was previously known as _bug_ 2444 at http://mercurial.selenic.com/bts/issue2444 Imported an attachment (id=1471) Imported an attachment (id=1472)