Bug 470049 - invariant violation during mtn commit
invariant violation during mtn commit
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: monotone (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Roland McGrath
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-05 09:02 EST by Petr Machata
Modified: 2015-05-04 21:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-05 09:55:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
debugging log (1.43 KB, text/plain)
2008-11-05 09:02 EST, Petr Machata
no flags Details
The debug log of failing mtn ls keys (4.67 KB, text/plain)
2008-12-02 07:10 EST, Petr Machata
no flags Details

  None (edit)
Description Petr Machata 2008-11-05 09:02:59 EST
Created attachment 322571 [details]
debugging log

Description of problem:
During the commit, I'm getting this:
mtn: beginning commit on branch 'com.redhat.elfutils.pmachata.threads'
mtn: fatal: std::logic_error: paths.cc:728: invariant 'I(!empty())' violated
mtn: this is almost certainly a bug in monotone.
mtn: please send this error message, the output of 'mtn version --full',
mtn: and a description of what you were doing to monotone-devel@nongnu.org.
mtn: wrote debugging log to /home/petr/elfutils-mtn/threads/elfutils/_MTN/debug
mtn: if reporting a bug, please include this file

Given this is Fedora package, I'm filing this as a Fedora bug, as opposed to sending a message to monotone-devel, as the error message indicates.

Version-Release number of selected component (if applicable):
monotone-0.41-1.fc9.x86_64

How reproducible:
Always.

Steps to Reproduce:

[petr@dhcp-lab-130 ~]$ mkdir -p mdb
[petr@dhcp-lab-130 ~]$ mtn --db mdb/elfutils.mtn db init
[petr@dhcp-lab-130 ~]$ mtn --db mdb/elfutils.mtn pull ssh://pmachata@mtn.fedorahosted.org/mtn/elfutils/db.mtn 'com.redhat*elfutils*'
mtn: setting default server to ssh://pmachata@mtn.fedorahosted.org/mtn/elfutils/db.mtn
mtn: setting default branch include pattern to 'com.redhat*elfutils*'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to ssh://pmachata@mtn.fedorahosted.org/mtn/elfutils/db.mtn
mtn: finding items to synchronize:
mtn:  bytes in | bytes out | certs in | revs in
mtn:     4.8 k |       171 |        0 |       0
mtn:  bytes in | bytes out |    certs in |     revs in
mtn:    14.9 M |       179 | 9,833/9,833 | 2,414/2,414
mtn: successful exchange with ssh://pmachata@mtn.fedorahosted.org/mtn/elfutils/db.mtn
[petr@dhcp-lab-130 ~]$ mtn --db mdb/elfutils.mtn co -b com.redhat.elfutils.pmachata.threads th
[petr@dhcp-lab-130 ~]$ cd th/
[petr@dhcp-lab-130 th]$ patch -p0 < ~/d
patching file libdw/ChangeLog
patching file libdw/dwarf_begin.c
patching file libdw/dwarf_end.c
patching file libdw/libdwP.h
[petr@dhcp-lab-130 th]$ mtn commit -m 'Add a lock to struct Dwarf.  init/fini it appropriately.'
mtn: beginning commit on branch 'com.redhat.elfutils.pmachata.threads'
mtn: fatal: std::logic_error: paths.cc:728: invariant 'I(!empty())' violated
mtn: this is almost certainly a bug in monotone.
mtn: please send this error message, the output of 'mtn version --full',
mtn: and a description of what you were doing to monotone-devel@nongnu.org.
mtn: wrote debugging log to /home/petr/th/_MTN/debug
mtn: if reporting a bug, please include this file

Actual results:
As stated above.

Expected results:
Succeeding commit.

Additional info:
$ mtn version --full
monotone 0.41 (base revision: 9b264ec9247ce99cd1fdc5293e869c1a60b01c4c)
Running on          : Linux 2.6.26.6-79.fc9.x86_64 #1 SMP Fri Oct 17 14:20:33 EDT 2008 x86_64
C++ compiler        : GNU C++ version 4.3.0 20080428 (Red Hat 4.3.0-8)
C++ standard library: GNU libstdc++ version 20080428
Boost version       : 1_34_1
Changes since base revision:
unknown
Comment 1 Thomas Moschny 2008-11-05 10:00:50 EST
You do have a monotone key, don't you? What does 'mtn ls keys' show?
Comment 2 Petr Machata 2008-11-05 10:07:47 EST
It shows the same error message.

I recently switched from i386 to x86_64, and just copied all my dotfiles over from the old machine.  Could that be a problem?
Comment 3 Petr Machata 2008-11-05 10:08:49 EST
(I tried to remove .monotone and "mtn ls keys" still fails.)
Comment 4 Thomas Moschny 2008-12-02 02:46:28 EST
Could you please add a complete --debug log for the failing command(s)?
Comment 5 Petr Machata 2008-12-02 07:07:03 EST
I just tried the above routine again, and it works.  I did an update in the meantime (27 Oct), but I don't remember if there was monotone update.  The full version is now as follows:

monotone 0.41 (base revision: 9b264ec9247ce99cd1fdc5293e869c1a60b01c4c)
Running on          : Linux 2.6.27.5-41.fc9.x86_64 #1 SMP Thu Nov 13 20:29:07 EST 2008 x86_64
C++ compiler        : GNU C++ version 4.3.0 20080428 (Red Hat 4.3.0-8)
C++ standard library: GNU libstdc++ version 20080428
Boost version       : 1_34_1
Changes since base revision:
unknown

I still have the original mtn db handy (and can keep it that way), where the command fails, and will attach the debug log as requested, in case it's still interesting for you.
Comment 6 Petr Machata 2008-12-02 07:10:53 EST
Created attachment 325363 [details]
The debug log of failing mtn ls keys
Comment 7 Thomas Moschny 2008-12-02 09:06:32 EST
Monotone doesn't know the keydir - there is most likely no keydir entry in the _MTN/options file of your working copy.

Giving --confdir=/home/petr/.monotone or --keydir=/home/petr/.monotone/keys when you commit should fix the problem. After this, there should be a line
  keydir "/home/petr/.monotone/keys"
in _MTN/options. You could also manually add such a line.

The mtn devs are aware of the problem. The next version will contain code to at least detect that situation (missing entry in the options file).
Comment 8 Petr Machata 2008-12-02 09:17:49 EST
Great, that's it.  When I add the option to the option file, I can commit.  So that explains what happened, now what do we do with this bug report?  Close it UPSTREAM?
Comment 9 Thomas Moschny 2008-12-05 09:55:42 EST
Fixed upstream in rev 1dc6fb315ee1955a2ae3ce7d0b5095a25a18ed4b.

(In reply to comment #8)
> now what do we do with this bug report?  Close it UPSTREAM?

Yes, I think that's the right thing to do. We could try to backport the fix, but that's probably not worth the effort.

Note You need to log in before you can comment on or make changes to this bug.