Re: [Monotone-devel] mtn mv, assertion violated.

[Nathaniel Smith]

On Wed, Apr 26, 2006 at 11:34:16AM +0100, Neil Murphy wrote:
> I seem to have managed to crash montone. The error messages asks me to 
> report the problem so I am.

Thanks!

> (BTW Monotone is great otherwise! Vastly better than CVS. Changesets are 
> very nice. The netsync access control system could provide more feedback 
> though; It took me ages to realize I had single not double quotes in my 
> read-permissions file.)

Yeah, known issue...


On the actual bug: the short version is, run:
  $ cd /e/monotone/asic3/switch/verilog
  $ mtn mv ../../common/verilog ../../mac_plus/verilog/timescale.v
  $ mtn add ../../common/verilog
  $ mtn mv --execute ../../mac_plug/verilog/timescale.v ../../common/verilog

The actual analysis, if you're curious and for those who might want to
fix the bug(s), follows :-).

> /e/monotone/asic3/switch/verilog $ mtn mv --execute 
> ../../mac_plus/verilog/timescale.v ../../common/verilog/
> mtn: adding common to workspace manifest
> mtn: renaming mac_plus/verilog/timescale.v to common/verilog in 
> workspace manifest
> mtn: warning: destination common/verilog already exists in workspace, 
> skipping

Hmm, so here monotone got a little confused; the case we aren't
handling right (I guess) is moving a file into an _unversioned_
directory.  Monotone correctly guessed that you probably wanted to
add "common", but it didn't figure out that you also wanted to version
"common/verilog".  So it just figured you were renaming the file
"../../mac_plus/verilog/timescale.v" to have the name
"../../common/verilog", and happily recorded that intention.

Then, of course, the --execute part failed, but it does that
separately.

(The trailing / doesn't make a difference, either, because that gets
normalized out early on.  Technically this is probably wrong in
various really obscure cases like this; not sure if the work involved
in making that not be the case is at all justifiable.  I don't really
understand the posix rules for trailing /'s anyway.)

Perhaps we should wait to record the new _MTN/work until after the
--execute has succeeded?

Perhaps we should somehow notice that the target of a rename already
exists in the filesystem as a directory, and be smarter about that?
This smells like a specific patch for a more general issue, though;
the semantics are a little non-obvious.

> /e/monotone/asic3/switch/verilog $ mtn status
> mtn: warning: expected file 'common/verilog', but it is a directory.
> mtn: warning: missing common/verilog
> mtn: misuse: 1 missing files; use 'mtn ls missing' to view
> mtn: misuse: to restore consistency, on each missing file run either
> mtn: misuse: 'mtn drop FILE' to remove it permanently, or
> mtn: misuse: 'mtn revert FILE' to restore it
> mtn: misuse: or to handle all at once, simply 'monotone drop --missing'
> mtn: misuse: or 'monotone revert --missing'

This is giving a hint as to what happened...

> /e/monotone/asic3/switch/verilog $ mtn mv --execute 
> ../../mac_plus/verilog/timescale.v ../../common/verilog/timescale.v
> mtn: fatal: std::logic_error: 
> /home/lapo/packaging/tmp/monotone-0.26/roster.hh:128: invariant 
> 'I(static_cast<bool>(d))' violated
> mtn:
> mtn: this is almost certainly a bug in monotone.
> mtn: please send this error message, the output of 'mtn --full-version',
> mtn: and a description of what you were doing to address@hidden
> mtn: wrote debugging log to /e/monotone/asic3/_MTN/debug
> mtn: if reporting a bug, please include this file

And here we try to rename a file the doesn't exist (since as far as
monotone is concerned, the file ../../mac_plus/verilog/timescale.v has
been renamed already and there is no longer any file there), to a
location that doesn't make any sense (because as far as monotone
knows, ../../common/verilog is a file, so
../../common/verilog/timescale.v is a... strange location).  I'm
_guessing_ the latter is what causes the invariant failure -- it's
easy to imagine we forgot to put in a more specific error check for
this -- but it's a little strange we don't error out first on the
nonexistent source.

> ----- begin 'full_version_string' (in int cpp_main(int, char**), at 
> /home/lapo/packaging/tmp/monotone-0.26/monotone.cc:283)
> monotone 0.26 (base revision: unknown)
> Running on          : CYGWIN_NT-4.0 1.5.19(0.150/4/2) 2006-01-20 13:28 i686
> C++ compiler        : GNU C++ version 3.4.4 (cygming special) (gdc 0.12, 
> using dmd 0.125)
> C++ standard library: GNU libstdc++ version 20050519
> Boost version       : 1_33_1
> Changes since base revision:
> format_version "1"
> 
> new_manifest [622264d4ccf1461336f8f4a43032596ee8b4e98f]
> 
> old_revision [cdf0e31265a271a8e9a4126e022c3018306bf3dc]
> 
> add_file "bin/zshdiff"
>  content [0166ccf2a008b6e18437b590b865a5e829349c14]
> 
> patch ".Xdefaults"
>  from [d7ffb8c0dfb33a3e7b6a76a74c61ef508ecc7657]
>    to [ac6d1239dba0b440920c1196fb152845ca4af1e3]
> 
> patch ".ssh/known_hosts"
>  from [2be8faf9613dfacd44b9ffd900fb28b5c0c05ce7]
>    to [bf358444e41111b0f752c028890e07ce68289c6e]
> 
> patch ".zshrc"
>  from [ec8990aaaa138c84cf57b336a55f02ab2cc1dfb4]
>    to [8534c39dcb175770811798a86164f2dbee1d50bd]
> 
>   set "bin/zshdiff"
>  attr "mtn:execute"
> value "true"
> -----   end 'full_version_string' (in int cpp_main(int, char**), at 
> /home/lapo/packaging/tmp/monotone-0.26/monotone.cc:283)

Oh my!  This is an amusing little bug too :-).  Looks like this binary
was built in a dir with no _MTN directory in it, and it discovered
Lapo's ~/_MTN directory instead...

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff