Bug 255261

Created attachment 173081 [details]
valgrind output of failing star command

Created attachment 173101 [details]
valgrind output of same star command without -data-change-warn

Created attachment 173461 [details]
Fix

This patch should fix this issue

star-1.5a84-2.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Thank you for the fast response.  I installed the star-1.5a84-2.fc7 RPM from 
updates.

It gets farther, and some star -c commands work, but many fail with segfaults 
after a brief period.  Examples:

star -c H=exustar -dump -xattr -xfflags -fifo 
fs=64m -fifostats -block-number -data-change-warn
-match-tree -acl -atime -time -not pattern=/home/backups
pattern=/home/E:/Etemp pattern=/etc pattern=/opt pattern=/usr pattern=/var 
pattern=/J: pattern=/L: pattern=/M: pattern=/N: 
file=/O:/ATHLON/home.Linux.DMWsysbu.star -z -C / /home

star: Operation not supported. Error moving extended header '././@PaxHeader'.
Command terminated by signal 11

Similar backup of /usr fails with signal 11 after 26 seconds/38MB, but does not 
give the Operation Not Supported message.
Similar backup of /opt failed with signal 11 after 5 seconds/47MB, like /usr.
Similar backup of /etc succeeded.  7 seconds/98MB.
Similar backup of all the miscellaneous stuff in / failed with signal 11 after 
7 seconds/39MB.

Is there any additional data collection you need?

Created attachment 180281 [details]
valgrind trace

Oops, here's valgrind trace of 

star -c H=exustar -dump -xattr -xfflags -fifo 
fs=64m -fifostats -block-number -data-change-warn
-match-tree -acl -atime -time -not pattern=/home/backups
pattern=/home/E:/Etemp pattern=/etc pattern=/opt pattern=/usr pattern=/var 
pattern=/J: pattern=/L: pattern=/M: pattern=/N: 
file=/O:/ATHLON/home.Linux.DMWsysbu.star -z -C / /home

(In reply to comment #5)
> Thank you for the fast response.  I installed the star-1.5a84-2.fc7 RPM from 
> updates.
> 
> It gets farther, and some star -c commands work, but many fail with segfaults 
> after a brief period.  Examples:
> 
> star -c H=exustar -dump -xattr -xfflags -fifo 
> fs=64m -fifostats -block-number -data-change-warn
> -match-tree -acl -atime -time -not pattern=/home/backups
> pattern=/home/E:/Etemp pattern=/etc pattern=/opt pattern=/usr pattern=/var 
> pattern=/J: pattern=/L: pattern=/M: pattern=/N: 
> file=/O:/ATHLON/home.Linux.DMWsysbu.star -z -C / /home
> 
> star: Operation not supported. Error moving extended header '././@PaxHeader'.
> Command terminated by signal 11
> 
> Similar backup of /usr fails with signal 11 after 26 seconds/38MB, but does not 
> give the Operation Not Supported message.
> Similar backup of /opt failed with signal 11 after 5 seconds/47MB, like /usr.
> Similar backup of /etc succeeded.  7 seconds/98MB.
> Similar backup of all the miscellaneous stuff in / failed with signal 11 after 
> 7 seconds/39MB.
> 
> Is there any additional data collection you need?
> 

star is now compiled with -O0 flag (no optimization). The segfaults are caused
by wrong optimization done by gcc. The impact on speed with this change is not
so high, I've tested to archive ~2000 files (322MBytes) and it took 46sec with
-O2, and 48sec with -O0. If you notice a larger impact on performance of star
after update, please let me know. According to upstream, this software is mainly
designed for running on *Solaris and to be compiled with SunPro C compiler.

(In reply to comment #7)
> star is now compiled with -O0 flag (no optimization). The segfaults are 
caused
> by wrong optimization done by gcc. The impact on speed with this change is 
not
> so high, I've tested to archive ~2000 files (322MBytes) and it took 46sec 
with
> -O2, and 48sec with -O0. If you notice a larger impact on performance of star
> after update, please let me know. According to upstream, this software is 
mainly
> designed for running on *Solaris and to be compiled with SunPro C compiler.
> 

That sounds reasonable, Dan.  I'll give it a try, but 1.5a84-3.fc7 has not yet 
become available in the updates repository.

star-1.5a84-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

OK, I finally figured out I needed to --enablerepo=updates-testing to install 
this fix.  I've run several backups, and they all finished.  Ran verifies on 
all the backups, immediately after each backup finished. Tested a restore.  Did 
see some odd mismatches between the backups and the verifies, though.  Run a 
backup, immediate run a diff, and get "different sparse" messages for files 
which cannot reasonably have changed.  This sort of thing occurred for many of 
the backups/diffs I ran.  Please tell me if these are likely related to this 
problem, or are a separate bug, or are a user error.  Here is an example:


========== creating backup: star -c H=exustar -dump -xattr -xfflags -fifo 
fs=64m -fifostats -block-number -data-change-warn -match-tree -acl -atime -time -not 
pattern=/home/backups pattern=/home/E:/Etemp pattern=/etc pattern=/opt 
pattern=/usr pattern=/var pattern=/J: pattern=/L: pattern=/M: pattern=/N: 
file=/O:/ATHLON/home.Linux.DMWsysbu.star -z -C / /home

star: fifo had 130935 puts 224146 gets.
star: fifo was 1 times empty and 82 times full.
star: fifo held 67102720 bytes max, size was 67112960 bytes
star: 224146 blocks + 0 bytes (total of 2295255040 bytes = 2241460.00k).
star: Total time 215.261sec (10412 kBytes/sec)


=========== verifying data: star -diff diffopts=!atime,ctime,lmtime -fifo 
fs=64m -acl -atime -time -not file=/O:/ATHLON/home.Linux.DMWsysbu.star -z -C /

diffopts=perm,type,nlink,uid,gid,uname,gname,size,data,rdev,hardlink,symlink,sympath,sparse,mtime,dir,acl,xattr,fflags
star: WARNING: skipping leading '/' on filenames.
home/htest/: different mtime
home/htest/.spamassassin/auto-whitelist: different sparse
home/htest/.spamassassin/bayes_toks: different sparse
home/htest/.spamassassin/bayes_seen: different sparse
home/htest/.kde/share/config/: different mtime
home/htest/.kde/share/config/kickerrc: different mtime
home/htest/.kde/share/config/kdeglobals: different mtime
home/htest/.kde/share/apps/kcookiejar/: different mtime
home/htest/.kde/share/apps/kcookiejar/cookies: different mtime
home/HUSBAND/.opera/mail/mailbase.dat: different sparse
home/HUSBAND/.opera/mail/lexicon/lexicon_16384.dat: different sparse
home/HUSBAND/.opera/mail/lexicon/lexicon_65536.dat: different sparse
home/HUSBAND/.opera/mail/indexer/indexer_8192.dat: different sparse
home/HUSBAND/.opera/mail/indexer/indexer_64.dat: different sparse
home/HUSBAND/.opera/mail/indexer/indexer_4096.dat: different sparse
home/HUSBAND/.opera/mail/indexer/indexer_32768.dat: different sparse
home/WIFE/.mozilla/WIFE/s4r0yse3.slt/cert8.db: different sparse
home/WIFE/.mozilla/WIFstar: 224146 blocks + 0 bytes (total of 2295255040 bytes 
= 2241460.00k).
star: Total time 66.154sec (33882 kBytes/sec)
E/Cache/_CACHE_003_: different sparse



Opera is no longer installed on this machine, so the /home/HUSBAND/.opera files 
being different appears to be nonsense, and user WIFE has not been logged on 
since the machine was last booted, so /home/WIFE files being different also 
appears nonsense.

If the oddball differences can be explained, then I think you have fixed the 
problem.
Thank you.
Douglas Woostewr

I think the "different sparse" errors are caused because you don't have used the
-sparse option when creating the backup. Please re-run your test with this option.

OK, thanks.  I'll try that and report back in a day or two.

I've rerun with -sparse .  No more strange difference messages.  That does look 
like it was a user error on my part.  All the backups ran and verified.  I 
tried a different set of test restores this time, and they came out OK.  I 
think this can be considered fixed and confirmed.  Thank you very much for your 
prompt help.

Douglas

star-1.5a84-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Have the compiler bugs, that forced you to disable optimization,
been fixed meanwhile?

Compiler bugs seems to be fixed, star no longer segfaulting (at least what I have tested) due to optimalization flag. Reenabled optimalization - however, it seems that star/names.c and libfind/names.c source file is missing in upstream tarball of final star-1.5 (I had to use names.c file from star-1.5a89 to compile it). Is it intentional or just by accident?

names.c is no longer needed.

The name is now libfind/idcache.c 

Did you destroy the makefiles?

I use all.mk as Makefile to disable fat binary ... and names.c is included in those "smaller" makefiles as necessary (in star/cpio.mk, star/gnutar.mk, star/pax.mk, star/star_fat.mk, star/star.mk, star/suntar.mk) ... so I guess this is not fault on Red Hat side ...

(sorry, star_fat.mk obviously not - only those others)

Since a few years, it it no longer recommended to create non-fat binaries.

I recommend to compile things the way they are delivered.

BTW: there are some small bugs in star-1.5 star are fixed in

ftp://ftp.berlios.de/pub/schily/

the complete schily source consolidation.