Re: Error 0

Daniel Grund <[email protected]> wrote:

> On 08.01.2008 11:23, Joerg Schilling wrote:
>
> > > I call star-1.5a87 like this:
> > >
> > > star c -silent -no-statistics -M -multivol new-volume-script=3D"/usr/=
local/bin/yacdbak.cdrecord root 1 noburn" VOLHDR=3D"FreeBSD 7.0-RC1 2008-01=
-08 03:20+0100 Level 1" -dump level=3D1 -dumpmeta tardumps=3D/var/db/yacdba=
k/root.snapshots -wtardumps -p -match-tree -tsize=3D66534 -no-fifo -nodump =
artype=3De xustar -sparse file=3D/var/tmp/yacdbak.image fs-name=3D/ dumpdat=
e=3D/var/tmp/timestamp -dodesc -not .snap -not lost+found -C=3D/.snap/backu=
pmount .
>
> > -	You are not using star correctly.
>
> > - You found a bug: star should not allow you to specify more than
> >   one start directory.
>
> > -	I recommend to first clean up the command line and check whether
> > 	the incorrect command line is the reason for the problem.
>
> Tweaking the command line did not help. I called star under gdb:
>
> Starting program: /usr/local/bin/star -c -silent -no-statistics -M -multi=
vol new-volume-script=3D"/root/bin/yacdbak/bin/yacdbak.cdrecord root 1 nobu=
rn" VOLHDR=3D"FreeBSD 7.0-RC1 2008-01-08 14:17+0100 Level 1" -dump level=3D=
1 -dumpmeta tardumps=3D/var/db/yacdbak/root.snapshots -wtardumps -p -match-=
tree -tsize=3D133068 -no-fifo -nodump artype=3Dexustar -sparse file=3D/tmp/=
secure/yacdbak.image fs-name=3D/ dumpdate=3D/tmp/secure/timestamp -dodesc -=
not pattern=3D.snap -C "/.snap/backupmount" .
> Type of this level 1P dump: partial
> Date of this level 1P dump: Tue Jan  8 14:17:16 2008
> Date of last level 0P dump: Fri Nov 30 16:44:31 2007
> /usr/local/bin/star: Error 0. Error moving extended header '././@PaxHeade=
r'.
>
> Program received signal SIGSEGV, Segmentation fault.
> movebytes (fromv=3D0x28300000, tov=3D0x28205800, cnt=3D10240) at movebyte=
s.c:57
> 57                                              DO8 (*tol++ =3D *froml++);
> (gdb) bt
> #0  movebytes (fromv=3D0x28300000, tov=3D0x28205800, cnt=3D10240) at move=
bytes.c:57

This is a completely different view than with your last mail.

The last mail makes me belive that there was a cal to move_to_arch() with a =

negative size. Now I see 10240.

> #1  0x0806dc13 in move_to_arch (move=3D0xbfbf2a48, p=3D0x28205800 "", amo=
unt=3D10240)
>     at movearch.c:74
> #2  0x0805d851 in cr_file (info=3D0xbfbf2c54, func=3D0x806dbe0 <move_to_a=
rch>,
>     arg=3D0xbfbf2a48, amt=3D10240, text=3D0x808ac95 "moving extended head=
er") at create.c:1321
> #3  0x080588f8 in write_xhdr (type=3DVariable "type" is not available.
> ) at xheader.c:344
> #4  0x0805917c in info_to_xhdr (info=3D0xbfbf53b4, ptb=3D0xbfbf3208) at x=
header.c:549
> #5  0x08053fbe in put_tcb (ptb=3D0xbfbf3208, info=3D0xbfbf53b4) at header=
.c:1098
> #6  0x0805edf4 in createi (
>     sname=3D0xbfbf4fb3 "usr/local/lib/perl5/site_perl/5.8.8/mach/auto",

How many file name entries has this directory?


>     name=3D0xbfbf4fb3 "usr/local/lib/perl5/site_perl/5.8.8/mach/auto", na=
mlen=3D45,
>     info=3D0xbfbf53b4, last=3D0xbfbf546c) at create.c:1520
> #7  0x0805f237 in createi (sname=3D0xbfbf62f3 "usr/local/lib/perl5/site_p=
erl/5.8.8/mach",
>     name=3D0xbfbf62f3 "usr/local/lib/perl5/site_perl/5.8.8/mach", namlen=
=3D41,
>     info=3D0xbfbf66f4, last=3D0xbfbf67ac) at create.c:1639
> #8  0x0805f237 in createi (sname=3D0xbfbf7633 "usr/local/lib/perl5/site_p=
erl/5.8.8",
>     name=3D0xbfbf7633 "usr/local/lib/perl5/site_perl/5.8.8", namlen=3D36,=
 info=3D0xbfbf7a34,
>     last=3D0xbfbf7aec) at create.c:1639
> #9  0x0805f237 in createi (sname=3D0xbfbf8973 "usr/local/lib/perl5/site_p=
erl",
>     name=3D0xbfbf8973 "usr/local/lib/perl5/site_perl", namlen=3D30, info=
=3D0xbfbf8d74,
>     last=3D0xbfbf8e2c) at create.c:1639
> #10 0x0805f237 in createi (sname=3D0xbfbf9cb3 "usr/local/lib/perl5",
>     name=3D0xbfbf9cb3 "usr/local/lib/perl5", namlen=3D20, info=3D0xbfbfa0=
b4, last=3D0xbfbfa16c)
>     at create.c:1639
> #11 0x0805f237 in createi (sname=3D0xbfbfaff3 "usr/local/lib",
>     name=3D0xbfbfaff3 "usr/local/lib", namlen=3D14, info=3D0xbfbfb3f4, la=
st=3D0xbfbfb4ac)
>     at create.c:1639
> #12 0x0805f237 in createi (sname=3D0xbfbfc333 "usr/local", name=3D0xbfbfc=
333 "usr/local",
>     namlen=3D10, info=3D0xbfbfc734, last=3D0xbfbfc7ec) at create.c:1639
> #13 0x0805f237 in createi (sname=3D0xbfbfd675 "usr", name=3D0xbfbfd675 "u=
sr", namlen=3D4,
>     info=3D0xbfbfda74, last=3D0xbfbfdb2c) at create.c:1639
> #14 0x0805f237 in createi (sname=3D0xbfbfe8a4 ".", name=3D0xbfbfe8a4 ".",=
 namlen=3D2,
>     info=3D0xbfbfe178, last=3D0x0) at create.c:1639
> #15 0x0805fb63 in create (name=3D0xbfbfe8a4 ".", Hflag=3D0, forceadd=3D1)=
 at create.c:465
> #16 0x0804bdd6 in star_create (ac=3D1, av=3D0xbfbfe5b8) at star_fat.c:766
> #17 0x08051751 in main (ac=3D0, av=3D0x0) at star_fat.c:537
>
>
> The command line does not seem to cause the problem.
>
>
> I recompiled star again with smake COPTX=3D"-ggdb -O0" LOPTX=3D-ggdb and
> the sigsegv went away. Previously I had let smake choose the
> optimization level itself. No CLFAGS was set in the shell or in
> /etc/make.conf.
>
> Could star be incompatible with this gcc:
>
> gcc (GCC) 4.2.1 20070719  [FreeBSD]

Star works correctly with many c-compilers. It may be that you found a bug =
in =

your version of gcc. Bugs in the optimizer are not uncommon...

J=F6rg

-- =

 EMail:[email protected] (home) J=F6rg Schilling D-13353 Be=
rlin
       [email protected]                (uni)  =

       [email protected]     (work) Blog: http://schily.blogspo=
t.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/sch=
ily