monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Usher crashes


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Usher crashes
Date: Sat, 13 May 2006 18:16:36 -0500

On Sat, 2006-05-13 at 12:22 -0300, Jeronimo Pellegrini wrote:
> Hi.
> I just compiled usher, and started it:
> 
> $ ./usher -m "mtn -kmy_key" -a 127.0.0.1:10000 usher.cfg 

It treats the -m argument as an executable name, not a command line. So
it'll be looking for an execuable named "mtn -kmy_key", not looking for
an execuable named "mtn" and giving the "-kmy_key" argument. Really I
should probably replace this argument with a line in the config file,
which could allow for this.

> usher.cfg has the following:
> 
> ================
> userpass "jp" "no_I_wont_tell_you"
> 
> server "phd"
> host "localhost"
> pattern "info.aleph0.phd*"
> local "-d" "/home/jeronimo/monotone/phd.db"
> 
> server "main"
> host "localhost"
> pattern "info.aleph0.*"
> local "-d" "/home/jeronimo/monotone/main.db"
> =================
> 
> I hope that matching first "info.aleph0.phd*" and later "info.aleph0.*"
> is not a problem...

I see it needs better documentation.

It finds a matching server by first looking for one with a correct
'host' line. If there isn't a matching host line, then it looks for a
matching 'pattern' line.

The 'host' line is matched as a prefix of the hostname that the client
is given to talk to, and the 'pattern' line is matched as a prefix of
the include pattern. In each case, it takes the longest one that
matches.

Note that the 'pattern' line is a string prefix of the include pattern,
not a glob.

Also, you still have to provide the pattern argument that the serve
command requires in the 'local' line. And since it sounds like this
argument is going away soon, I'm not going to have it try to guess it.

> Now, from another host:
> 
> ==================
> $ mtn push rumi
> mtn: connecting to rumi
> mtn: error: I/O failure while talking to peer rumi, disconnecting
> ==================
> 
> And at rumi, who is running usher:
> 
> ==================
> Segmentation fault
> ==================
> 
> I ran usher under gdb (the same command line options were passed), and got 
> this:
> 
> =================
> Program received signal SIGSEGV, Segmentation fault.
> server_manager::prefix::cmp (this=0xbfffeffc, address@hidden) at 
> basic_string.h:269
> 269           { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }
> (gdb) where
> #0  server_manager::prefix::cmp (this=0xbfffeffc, address@hidden) at 
> basic_string.h:269
> #1  0x0805cee3 in server_manager::prefix::operator== (this=0xbfffeffc, 
> address@hidden) at server_manager.cc:55
> #2  0x0806041f in server_manager::connect_to_server (this=0xbfffefd0, 
> address@hidden, address@hidden) at stl_tree.h:176
> #3  0x08056421 in channel::process_selected (this=0x8081810, address@hidden, 
> address@hidden, address@hidden) at channel.cc:101
> #4  0x080675a9 in main (argc=6, argv=0x8081808) at stl_list.h:135
> ==================

This might be fixed now.

> Also, I noticed that usher will start and pretend that everything is OK,
> even if one of the local databases does not exist. Maybe the server
> could exit with an error, or at least issue a warning?

It doesn't actually parse the arguments in the 'local', it just passes
them on to the server. So it can't know there's a problem until the
server fails to start.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]