Nathaniel Smith wrote: > On Thu, Aug 24, 2006 at 11:16:09AM +0200, Detlef Vollmann wrote: > > So I did: > > $ mtn --db=/source/monotone/snapshot/oe-060823.mtn checkout > > --branch=org.openembedded.dev > > --revision=c9f0e213d8e0fdc01e39c1d5ebd4f3e5de4db6b1 > > > > and this is the command that is still running (after checking out > > about 140MB) ... > > Odd; I just ran exactly this command with the static linux/x86 0.29 > binary we distribute, and the checkout completed fine in not much time > at all. ~20 seconds CPU time, somewhat more than that real. I didn't find a real static binary, but only one that requires glibc 2.3, while my machine only has 2.2.3...
> What system are you on? I think that's the interesting point: My local copy of the database sits on a server with a really old installation (originally redhat 6.3 only only partly updated). The working copy sits on my workstation (not really up-to-date, but at least glibc 2.3.2 and gcc 3.2.2). The workstation accesses the server's files using NFS, but I had problems using monotone with a database over NFS. So I used the workstation to build a fully static binary for the server. On the server I mount the target directory of the workstation over NFS and do the checkout. Possibly that's the problem. I just ran a new pull and then the checkout again, and monotone went into the endless loop after only writing about 8MB to the target directory. So I started the checkout again, and this time it succeeded! So it's not a deterministic failure. > Is it possible your build is broken somehow? Actually, I don't think so, but you never know... > Can you determine where monotone is freezing up? Is it using CPU? As much as it can get (nearly 100% in top). > If > you attach to it with gdb, can you get a backtrace (by doing: > $ gdb `which mtn` `pidof mtn` > (gdb) backtrace > )? As I stripped the executable, the output is not very interesting: Attaching to program: /usr/local/bin/mtn, process 2612 0x08468605 in ?? () (gdb) bt #0 0x08468605 in ?? () #1 0x08467889 in ?? () #2 0x0830d9a8 in ?? () #3 0x0830da7e in ?? () #4 0x08383fb3 in ?? () #5 0x08384cfc in ?? () #6 0x0830f02f in ?? () #7 0x0814402b in ?? () #8 0x08145870 in ?? () #9 0x0814a7e2 in ?? () #10 0x080f3387 in ?? () #11 0x080a612e in ?? () #12 0x0829f6af in ?? () #13 0x082a3b7c in ?? () #14 0x0843fbc9 in ?? () > Does strace say anything interesting? As the output would be huge (it first writes lots of files/directories before running off), I didn't try this. But if you're interested, I can either build a non-stripped version, or run it under strace, or both. Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ Linux for PXA270 Colibri module: http://www.vollmann.ch/en/colibri/ _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
