Re: [Monotone-devel] monotone Fehler
Hallo Matthias, Matthias Jauernig wrote: mtn: Fataler Fehler: std::logic_error: paths.cc:415: Invariante 'I(utf8_validate(utf8(data)) !has_bad_component_chars(data) data != . data != ..)' verletzt mtn: Dies ist ganz bestimmt ein Fehler in monotone. ... Über eine Antwort (vll. war es ja ein Fehler von mir?) würde ich mich sehr freuen. Ja, das ist ein Fehler, oder wohl eher a missing feature: wie's scheint hast Du irgendwo Dateinamen, die kein gueltiges UTF-8 sind. Monotone hat da noch Muehe mit Sonderzeichen. Ich hab' das aber bisher nur mit 'mtn status' erlebt, da Du aber einen Checkout machen willst, ist mir kein Workaround bekannt. Du bist mit LC_ALL=German_Germany.1252 unterwegs... aber ich bin nicht mal sicher, ob das einen Einfluss hat. Wer hat denn das Repository angelegt? Funktioniert ein Checkout auf Unix mit LANG=de_DE.UTF-8 oder so? Gruesse Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] database or disk is full
Hello,
I'm running 4c7504ea753f15bde2abc80e0e74dfc0951735e4 and i can't db
init with it: i get sqlite error: database or disk is full.
Of course disk is not full at all. Debian Sid mtn-0.35 runs fine.
There is obviously an overflow somewhere. Please have a look at the
attached strace output:
pwrite64(5, \331\325\5\371 \241c\327\0\0\0\0[C\236\300\0\0\0\'\0\0...,
24, 18446744073069200889) = -1 EINVAL (Invalid argument)
Thanks.
--
Benoît Dejean
GNOME http://www.gnomefr.org/
LibGTop http://directory.fsf.org/libgtop.html
mtn: started up on Linux 2.6.22.1 #2 Fri Jul 20 11:08:07 CEST 2007 ppc
mtn: command line: './mtn', '--debug', '-d', '/tmp2/test.db', 'db', 'init'
mtn: set locale: LC_ALL=C
mtn: initial abs path is: /home/benoit/net.venge.monotone
mtn: searching for '_MTN' directory with root '/'
mtn: working root is '/home/benoit/net.venge.monotone'
mtn: initial relative path is ''
mtn: local dump path is _MTN/debug
mtn: setting dump path to /home/benoit/net.venge.monotone/_MTN/debug
mtn: opening rcfile '/home/benoit/.monotone/monotonerc'
mtn: '/home/benoit/.monotone/monotonerc' is ok
mtn: skipping nonexistent rcfile '_MTN/monotonerc'
mtn: started up on Linux 2.6.22.1 #2 Fri Jul 20 11:08:07 CEST 2007 ppc
mtn: command line: './mtn', '--debug', '-d', '/tmp2/test.db', 'db', 'init'
mtn: set locale: LC_ALL=C
mtn: initial abs path is: /home/benoit/net.venge.monotone
mtn: searching for '_MTN' directory with root '/'
mtn: working root is '/home/benoit/net.venge.monotone'
mtn: initial relative path is ''
mtn: local dump path is _MTN/debug
mtn: setting dump path to /home/benoit/net.venge.monotone/_MTN/debug
mtn: opening rcfile '/home/benoit/.monotone/monotonerc'
mtn: '/home/benoit/.monotone/monotonerc' is ok
mtn: skipping nonexistent rcfile '_MTN/monotonerc'
mtn: loading lua hook note_mtn_startup
mtn: lua failure: isfunction() in get_fn; stack = nil
mtn: Lua::ok(): failed
mtn: executing command 'db init'
mtn: options path is _MTN/options
mtn: converting 8 bytes from UTF-8 to IDNA ACE
mtn: converting 3 bytes from UTF-8 to IDNA ACE
mtn: branch name is 'net.venge.monotone'
mtn: sqlite error: 13: database or disk is full
mtn: schema_migration.cc:101: detected error 'E(false)' violated
mtn: saving current work set: 4 items
mtn: finished saving work set
mtn: contents of work set:
mtn: Current work set: 4 items
mtn: - begin 'system_flavour' (in virtual void sanity::initialize(int,
char**, const char*), at sanity.cc:75)
mtn: Linux 2.6.22.1 #2 Fri Jul 20 11:08:07 CEST 2007 ppc
mtn: - end 'system_flavour' (in virtual void sanity::initialize(int,
char**, const char*), at sanity.cc:75)
mtn: - begin 'cmdline_string' (in virtual void sanity::initialize(int,
char**, const char*), at sanity.cc:89)
mtn: './mtn', '--debug', '-d', '/tmp2/test.db', 'db', 'init'
mtn: - end 'cmdline_string' (in virtual void sanity::initialize(int,
char**, const char*), at sanity.cc:89)
mtn: - begin 'string(lc_all)' (in virtual void sanity::initialize(int,
char**, const char*), at sanity.cc:94)
mtn: C
mtn: - end 'string(lc_all)' (in virtual void sanity::initialize(int,
char**, const char*), at sanity.cc:94)
mtn: - begin 'full_version_string' (in virtual void
mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23)
mtn: monotone 0.36 (base revision: 4c7504ea753f15bde2abc80e0e74dfc0951735e4)
mtn: Running on : Linux 2.6.22.1 #2 Fri Jul 20 11:08:07 CEST 2007 ppc
mtn: C++ compiler: GNU C++ version 4.2.1 (Debian 4.2.1-5)
mtn: C++ standard library: GNU libstdc++ version 20070901
mtn: Boost version : 1_34_1
mtn: Changes since base revision:
mtn: format_version 1
mtn:
mtn: new_manifest [7897ebf5bf51e4b1463e547a534861a530f6e8e2]
mtn:
mtn: old_revision [4c7504ea753f15bde2abc80e0e74dfc0951735e4]
mtn:
mtn: patch cert.cc
mtn: from [2e88ff620a6c09e14461f3d0e9d67ef0e1b8411d]
mtn:to [12203d62e7111e30f8cd45d2edd293abfb68b96d]
mtn: - end 'full_version_string' (in virtual void
mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23)
mtn: statement cache statistics
mtn: prepared 0 statements
mtn: error: sqlite error: database or disk is full
execve(./mtn, [./mtn, --debug, -d, /tmp2/test.db, db, init], [/* 54 vars */]) = 0
[...]
stat64(/tmp2/test.db, 0x7fabda98) = -1 ENOENT (No such file or directory)
stat64(/tmp2/test.db-journal, 0x7fabda98) = -1 ENOENT (No such file or directory)
open(/tmp2/test.db, O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 4
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
pread64(4, , 100, 0) = 0
fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}, 0x7fabd718) = 0
fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741826, len=510}, 0x7fabd718) = 0
fcntl64(4, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=1073741824, len=1}, 0x7fabd718) = 0
access(/tmp2/test.db-journal, F_OK) = -1 ENOENT (No such
Re: [Monotone-devel] missing public keys
Le mardi 02 octobre 2007 à 16:26 +0200, Benoît Dejean a écrit : Hello, I'm trying to checkout a branch but i'm missing a public key : mtn -d /home/monotone/foobar.db co --branch=com.foobar foobar mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' mtn: warning: ignoring unknown signature by '[EMAIL PROTECTED]' on '[EMAIL PROTECTED]:ZnIuY2xhcmlzeXM=]' [...] Where is it ?! Aren't the pubkeys stored along the branch ? Let me explain better. I'm missing two public keys: - an old key of mine that i used to commit on this project. - a key from a another developer. I though the keys were stored in the database. My old key was surely in my ~/.monotone/keys but i think i deleted it because i no longer needed it. Maybe that was a mistake. But the developer key, i never touched it: i got this developer's revisions only by sync'ing. I don't understand. These branches are 1 year old. Thanks. -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote: Hello, I'm running 4c7504ea753f15bde2abc80e0e74dfc0951735e4 and i can't db init with it: i get sqlite error: database or disk is full. Of course disk is not full at all. Debian Sid mtn-0.35 runs fine. I'm afraid this is a known bug. No one has yet been able to track it down. Does this happen 100% reproducibly for you? Does it go away if you rebuild the mtn executable with CFLAGS='-g -O0' CXXFLAGS='-g -O0'? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
Le vendredi 05 octobre 2007 à 09:27 -0700, Zack Weinberg a écrit : On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote: Hello, I'm running 4c7504ea753f15bde2abc80e0e74dfc0951735e4 and i can't db init with it: i get sqlite error: database or disk is full. Of course disk is not full at all. Debian Sid mtn-0.35 runs fine. I'm afraid this is a known bug. No one has yet been able to track it down. Does this happen 100% reproducibly for you? Yes. On db init, pull, etc. Does it go away if you rebuild the mtn executable with CFLAGS='-g -O0' CXXFLAGS='-g -O0'? I'm rebuilding right now. This makes me very nervous about silent database corruption :/ -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
Le vendredi 05 octobre 2007 à 09:27 -0700, Zack Weinberg a écrit : On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote: Hello, I'm running 4c7504ea753f15bde2abc80e0e74dfc0951735e4 and i can't db init with it: i get sqlite error: database or disk is full. Of course disk is not full at all. Debian Sid mtn-0.35 runs fine. I'm afraid this is a known bug. No one has yet been able to track it down. Does this happen 100% reproducibly for you? Does it go away if you rebuild the mtn executable with CFLAGS='-g -O0' CXXFLAGS='-g -O0'? Yep, it does not happen with -O0 -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote:
I'm afraid this is a known bug. No one has yet been able to track it
down. Does this happen 100% reproducibly for you? Does it go away if
you rebuild the mtn executable with CFLAGS='-g -O0' CXXFLAGS='-g -O0'?
Yep, it does not happen with -O0
Ok, next request - please rebuild the executable at -O2, *except*
sqlite/pager.c, which compile at -O0. The simplest way to do that is:
make clean
make mtn
^C the link
rm lib3rdparty.a
mv sqlite/lib3rdparty_a-pager.o{,.bad}
make mtn CFLAGS='-g -O0' CXXFLAGS='-g -O0'
And see if that works. If it does work, please also try it with that
one file compiled at -O1. If it does *not* work, please cycle through
the rest of the sqlite/ directory and see if you can find a single
file that when compiled at -O0 (with the rest of the files compiled at
-O2) makes the problem go away.
(If you'd rather not do all this work yourself, but don't mind giving
me an ssh-accessible account on your computer, please email me
off-list.)
zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote: Le vendredi 05 octobre 2007 à 09:27 -0700, Zack Weinberg a écrit : On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote: Hello, I'm running 4c7504ea753f15bde2abc80e0e74dfc0951735e4 and i can't db init with it: i get sqlite error: database or disk is full. Of course disk is not full at all. Debian Sid mtn-0.35 runs fine. I'm afraid this is a known bug. No one has yet been able to track it down. Does this happen 100% reproducibly for you? Yes. On db init, pull, etc. Does it go away if you rebuild the mtn executable with CFLAGS='-g -O0' CXXFLAGS='-g -O0'? I'm rebuilding right now. This makes me very nervous about silent database corruption :/ Not that likely. If things stopped working mtn would bail on you all over the place. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
On Fri, Oct 05, 2007 at 10:07:49AM +0200, Benoît Dejean wrote: Let me explain better. I'm missing two public keys: - an old key of mine that i used to commit on this project. - a key from a another developer. I though the keys were stored in the database. My old key was surely in my ~/.monotone/keys but i think i deleted it because i no longer needed it. Maybe that was a mistake. But the developer key, i never touched it: i got this developer's revisions only by sync'ing. I don't understand. These branches are 1 year old. I don't understand either; for every cert in a db, we're supposed to also have the corresponding public key in the db. What does ls keys say? Does the server (that you and the other developer presumably sync with) have the keys? -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
On Fri, Oct 05, 2007 at 07:54:51PM +0200, Benoît Dejean wrote: I'm rebuilding right now. This makes me very nervous about silent database corruption :/ Don't be too nervous -- as far as we can tell, it is some sort of weird sqlite issue, and monotone doesn't actually trust sqlite not to clobber and corrupt data all over the place. (Mostly we are distrustful because sqlite is at the mercy of the hard drive, and hard drives/disk controllers/filesystems like to do that sort of thing all the time, but it applies to bugs in sqlite too.) I can only think of two problems where monotone wouldn't notice the issue and bail out before any further damage could be done. These are: -- if sqlite silently started forgetting about some certs or returning weird result sets somehow, then we might silently act as if those certs didn't exist, so e.g. you thought you had checked out the head of the branch but actually you didn't. No permanant harm done (you'll just have to merge up, just like you would have if you hadn't pulled those certs at all), but could be confusing. -- if something managed to corrupt the data in your workspace before we hashed it -- say from hard drive/filesystem issues, or very precise (and unlikely) memory overflow that silently corrupted the buffer full of data we just read, etc. -- then we would go ahead and commit the corrupted data. (Basically we couldn't tell this apart from you actually modifying the file in the given way and then submitting that to commit; corrupt is in the eye of the beholder.) You can do also 'mtn db check' if it makes you feel better; that runs all of mtn's high-level consistency checks, as well as sqlite's built-in ones. -- Nathaniel -- IBM manual SENG-5155-01: Power Supply and Air Moving Device Installation Instruction for iSeries 820 and 5075. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.experiment.pcre ready for merge
I've updated the net.venge.monotone.experiment.pcre branch to latest mainline and to PCRE 7.4. It passes all the tests with no problems. I've dealt with the potential stack-overflow problem by imposing a sane recursion limit (normal regexps need only a few recursions at most; PCRE's default is effectively unlimited; I set it at 2000, which is supposed to be only a megabyte of stack - well within the 8MB of space that is typical) and I added PCRE's documentation on regular expression syntax to the main manual. I've also updated the autoconf goo - most of the boost search logic is not necessary if we stop using boost::regex. All tests pass, 'make distcheck' is in progress. I would like to merge this branch for 0.37, but I will let Richard or Nathaniel make the decision, especially as I have to leave now and won't be around much this weekend. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.pcre ready for merge
In message [EMAIL PROTECTED] on Fri, 5 Oct 2007 19:04:46 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw I've updated the net.venge.monotone.experiment.pcre branch to zackw latest mainline and to PCRE 7.4. It passes all the tests with zackw no problems. I've dealt with the potential stack-overflow zackw problem by imposing a sane recursion limit (normal regexps need zackw only a few recursions at most; PCRE's default is effectively zackw unlimited; I set it at 2000, which is supposed to be only a zackw megabyte of stack - well within the 8MB of space that is zackw typical) and I added PCRE's documentation on regular expression zackw syntax to the main manual. I've also updated the autoconf goo zackw - most of the boost search logic is not necessary if we stop zackw using boost::regex. All tests pass, 'make distcheck' is in zackw progress. zackw zackw I would like to merge this branch for 0.37, but I will let zackw Richard or Nathaniel make the decision, especially as I have to zackw leave now and won't be around much this weekend. I haven't come so far with releasing, unfortunately, and it will not happen this weekend, my son takes priority. Personally, I've no problems with having the PCRE stuff join mainline, especially since it (as I understand it) will greatly reduce the pain of having to deal with boost. A question: how much does the PCRE syntax differ from the boost::regex syntax? Is that relevant to know? Will it impact much on users, for example when dealing with .mtn-ignore? Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
