[chord] Re: problem with running sfsrodb

[Y Chen]

Hi

Not real solve the problem. Please help me.

After I modified the "directory => &directory" as I said in my previous message,
I got result as:

-----------------------
yin at df-01:~/chord-build/sfsrodb$ ./sfsrodb -s key_file -d /home/yin/tmp
sfsrodb: 0, sec/1k 0
sfsrodb: Database good from:
 Wed Jul 14 19:46:58 2004
until:
 Thu Jul 15 19:46:58 2004
-----------------------

As you see, I cannot get the magic string. The reason seems the program jumped
out from sfsrodb.C:913 "if (xdr_sfsro_data (x.xdrp (), &dat))" return false.
Here, "dat" defines as "sfsro_data dat (CFS_FSINFO)"

I've spent much time on this, please help me!!!

Yin











Quoting s0231189 at sms.ed.ac.uk:

> Hi
>
> Thank very much for the reply.
>
> (1) I found out the reason. Seems a small bug at function store_direcory() of
> <sfsrodb.C>, about line 504:
> ======================================
> void store_directory (sfsro_inode *inode, sfs_hash *fh, sfsro_data
> *directory)
> {
>   // XXX???  sfsro_data dat (SFSRO_DIRBLK);
>   size_t calllen = 0;
>   char *callbuf = NULL;
>   xdrsuio x (XDR_ENCODE);
>
> (504) if (xdr_sfsro_data ( x.xdrp(), directory)) {
>
> => if (xdr_sfsro_data ( x.xdrp(), &directory)) {
>
> ...
>
> }
>
> ("&" was missed here)
> =================================================
>
> (2) Can I ask the detail of dbm?
>
> dbm: vnode_num control_socket num_trials data_size file <f or s> nops seed
> [bw-f
> ile]
>
> - vnode_num: why there are only 49 nodes exist, I can still set
> vnode_num=1000?
> - num_trials: What's the biggest block number can I put here?
> - data_size: Is there any limitation of the size?
> - file: what's this for?
> - <f or s> : is that 'f' means search block operation, and 's' means insert
> block operation?
> - nops: is it the lookup times, which need to be set because normally cannot
> find the result in one lookup?
> - seed: if I set seed=1 when insert the block, can I find the same block with
> seed=1 with dbm?
> - [bw-file]: what's this for?
>
> (3) How to delete block I stored into the Chord system? Is there any
> information
> showing how blocks alocated to each peer?
>
> Thanks very much!
>
> Yin
>
>
>
> Quoting Frank Dabek <fdabek at MIT.EDU>:
>
> > This trace looks suspicious: exp_dir is an unreasonable pointer.
> >
> > let's back up a bit: can you run lsd and store blocks using the 'dbm'
> > program?
> >
> > --Frank
> >
> > Y Chen wrote:
> > > Hi
> > >
> > > The problem passes through main() function of sfsrodb.C and comes with
> > error
> > > when reaches the last line of main()
> > >
> > > main()
> > > {...
> > > return (sfsrodb_main (exp_dir, sk_file));
> > > }
> > >
> > > Can step futher till the line 812 of sfsrodb.C
> > >
> > > Near the beginning of the sfsrodb_main() function:
> > >
> > > int sfsrodb_main (const str root, const str keyfile)
> > > {
> > > ...
> > >
> > > 812  dhash_cli = New refcounted <dhashclient> (lsd_socket);
> > > ...
> > >
> > > Sorry to trouble you lot!
> > >
> > > Yin
> > >
> > >
> > >
> > >
> > > Quoting s0231189 at sms.ed.ac.uk:
> > >
> > >
> > >>Hi
> > >>
> > >>sorry, please ignor my previous message,
> > >>the result is as follow:
> > >>
> > >>
> > >>>gdb chord-build/sfsrodb/sfsrodb
> > >>
> > >>(gdb)run -s key_file -d tmp
> > >>Starting program: /home/yin/chord-build/sfsrodb/sfsrodb -s key_file -d
> tmp
> > >>
> > >>Program received signal SIGSEGV, Segmentation fault.
> > >>0x400fea3c in rpc_traverse<2147483647u> () from /lib/libsfsmisc.so.0
> > >>(gdb) bt
> > >>#0  0x400fea3c in rpc_traverse<2147483647u> () from /lib/libsfsmisc.so.0
> > >>#1  0x4030dea1 in rpc_traverse<XDR*> () from /lib/libsvc.so.0
> > >>#2  0x40312e9c in rpc_traverse<XDR*, sfsro_dirent> () from
> /lib/libsvc.so.0
> > >>#3  0x4030df43 in rpc_traverse<XDR*> () from /lib/libsvc.so.0
> > >>#4  0x4030e127 in rpc_traverse<XDR*> () from /lib/libsvc.so.0
> > >>#5  0x4030a382 in xdr_sfsro_data () from /lib/libsvc.so.0
> > >>#6  0x0804d68b in store_directory (inode=0xbffff5f0, fh=0xbffffaa0,
> > >>    directory=0xffffffff) at xdrmisc.h:386
> > >>#7  0x0804e901 in recurse_path (path={b = {p = 0x8087e18}},
> fh=0xbffffaa0)
> > >>    at /home/yin/sfsnet/sfsrodb/sfsrodb.C:728
> > >>#8  0x0804fd01 in sfsrodb_main (root=Cannot access memory at address
> > >>0xffffffff
> > >>) at str.h:45
> > >>#9  0x08051c23 in main (argc=0, argv=0xbffffd14) at str.h:101
> > >>
> > >>
> > >>
> > >>Thanks a lot
> > >>
> > >>Yin
> > >>
> > >>Quoting Frank Dabek <fdabek at MIT.EDU>:
> > >>
> > >>
> > >>>
> > >>>Y Chen wrote:
> > >>>
> > >>>>Hi
> > >>>>
> > >>>>I followed Chord HOWTO and tried sfsrodb for several times,
> > >>>>
> > >>>>chord-build/sfsrodb/sfsrodb -s key_file -d tmp
> > >>>>
> > >>>>but the result is :
> > >>>>
> > >>>>"Segmentation fault"
> > >>>>
> > >>>>What's the problem of this?
> > >>>>
> > >>>
> > >>>The problem is that the program accessed memory that it is not allowed
> > >>>to access by the operating system. This is usually the result of a bug
> > >>>in the program.
> > >>>
> > >>>If you provide me with a backtrace of the crash I might be able to debug
> > >>>it. Try:
> > >>>
> > >>>gdb sfsrodb <name of core file, e.g. sfsrodb.core>
> > >>>(gdb) bt
> > >>>
> > >>>and send me the results.
> > >>>
> > >>>However, sfsrodb is not under active development. I can't guarantee that
> > >>>we will fix any bug in a timely  manner.
> > >>>
> > >>>--Frank
> > >>>
> > >>>
> > >>>>Cheers,
> > >>>>
> > >>>>Yin
> > >>>
> > >>
> > >>
> > >
> > >
> >
>
>
>