segfaults with gcc 4.2.3

Just for everyone's information: compiling star on newer gcc (I tested 
version 4.2.3 on Linux) with any optimization flags other than -O0 may 
result in segfaults in dump mode, like this:

   kern.info: star[4067]: segfault at 087f3c74 eip 0807b104 esp bf9878ac error 4

as well as this error:

   star: Success. Error moving extended header '././ <at> PaxHeader'.

in restore mode.

Compiling with

   smake COPTX=-O0

gives a working executable, however.

Maybe something can be done about it from star's side; otherwise everyone is 
advised not to use optimization with this gcc version.

Lasse

_______________________________________________
Star-users mailing list
Star-users <at> lists.berlios.de
https://lists.berlios.de/mailman/listinfo/star-users

Re: segfaults with gcc 4.2.3

Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:

> Just for everyone's information: compiling star on newer gcc (I tested 
> version 4.2.3 on Linux) with any optimization flags other than -O0 may 
> result in segfaults in dump mode, like this:
>
>    kern.info: star[4067]: segfault at 087f3c74 eip 0807b104 esp bf9878ac error 4
>
> as well as this error:
>
>    star: Success. Error moving extended header '././ <at> PaxHeader'.
>
> in restore mode.

Is the problem also present with 4.0.2?

Jörg

--

-- 
 EMail:joerg <at> schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js <at> cs.tu-berlin.de                (uni)  
       schilling <at> fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: segfaults with gcc 4.2.3

* Message by -Joerg Schilling- from Mon 2008-03-03:
> Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:
> 
> > Just for everyone's information: compiling star on newer gcc (I tested 
> > version 4.2.3 on Linux) with any optimization flags other than -O0 may 
> > result in segfaults in dump mode, like this:
> >
> >    kern.info: star[4067]: segfault at 087f3c74 eip 0807b104 esp bf9878ac error 4
> >
> > as well as this error:
> >
> >    star: Success. Error moving extended header '././ <at> PaxHeader'.
> >
> > in restore mode.
> 
> Is the problem also present with 4.0.2?

No; tested on the same machine.

Is 4.0.2 a kind of 'gold' version?
The latest in the 4.0.x series is 4.0.4.

Lasse

_______________________________________________
Star-users mailing list
Star-users <at> lists.berlios.de
https://lists.berlios.de/mailman/listinfo/star-users

Re: segfaults with gcc 4.2.3

Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:

> > > as well as this error:
> > >
> > >    star: Success. Error moving extended header '././ <at> PaxHeader'.
> > >
> > > in restore mode.
> > 
> > Is the problem also present with 4.0.2?
>
> No; tested on the same machine.
>
> Is 4.0.2 a kind of 'gold' version?
> The latest in the 4.0.x series is 4.0.4.

It is available in binary from Blastwave

Jörg

--

-- 
 EMail:joerg <at> schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js <at> cs.tu-berlin.de                (uni)  
       schilling <at> fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

dealing with timestamp (in-)accuracy

In create.c of star-1.5a87, line 281, it reads:

   } else if (dumplevel > 0) {
      if (info->f_mtime > Newer.tv_sec) {
         /* EMPTY */
         ;
      } else if (info->f_ctime > Newer.tv_sec) {
         if (dumpmeta)
            info->f_xftype = XT_META;
      } else {
         return (FALSE);
      }

As far as I can see, this is the place where it is decided upon whether a 
file will be included in the current dump, or if it may be assumed that it is 
already included in a previous dump (and hence will not be included again). I 
wonder whether the checks shouldn't be for greater *or* *equal*, i.e.:

      if (info->f_mtime >= Newer.tv_sec) {
         /* EMPTY */
         ;
      } else if (info->f_ctime >= Newer.tv_sec) {

If 'tv_sec' means what I guess it means, namely seconds, then this is 
necessary, because (on Linux) it is no problem to sequentially create 
hundreds of files that have the same time if measured with an accuracy of 
seconds. (In fact, the unit of one second seems to be the accuracy of Linux 
file times.)

Further down, it reads:

Re: refuse to update certain files upon extraction

* Message by -Joerg Schilling- from Wed 2007-11-14:
> Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:
> 
> > What could star prevent from overwriting existing files when invoked like 
> > that:
> >
> >    star -xpU f=archive.tar
> >
> > ?
> >
> > I did some incremental dumps, restored them in a different filesystem and 
> > compared to the original one. Level 0 is no problem. On higher levels, 
> > however, certain files are not updated and hence differ from the current 
> > original. I checked the archives, and they contain the files in question in 
> > the correct version. But they are not extracted over the existing, outdated 
> > files! Neither when I try with -xpU, nor when I try with -xpU -restore. 
> > Extracting into an empty directory works (that way I found out that the files 
> > inside of the archive are the correct ones).

(...)
> As star always writes an error message, you should start to run star from
> script(1) to fetch such messages....

There was no error message (tried -vv, but not -debug). Some time passed 
since, and I do not have those files anymore. But I found a way to reproduce 
this, or at least something similar. How to do this is slightly complicated, 
and I do not understand it fully myself, so I go right to the results. There 
is a level 0 dump and a level 1 dump, and a file F that changed between the 
dumps. If the level 1 dump is extracted with 'star -xpU', then the file F is 
restored to the state it was when the dump was taken. However, if the two 

Re: timestamp(?) problems with incremental dumps

* Message by -Joerg Schilling- from Thu 2007-10-18:
> Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:
> 
> > > > The problem may be that the filesystem does not sync meta data fast enough.
> > >  
> > > To determine this, I must take a look at the file in question on the snapshot 
> > > which was used for the level 2 dump. I will do so in the next tests.
> >  
> > It's technically slightly more complicated than I thought, because I will 
> > have to keep the older snapshots around for this during the test. That's why 
> > I haven't looked into this yet.
> >
> > However, I discovered further details:
> >
> > > If this is the case, should a `sync' between touching the timestamp and 
> > > creating the snapshot help? (Well, it depends on the sync implementation and 
> > > the filesystem, I guess.)
> >
> > A single `sync' is not enough.
> >
> > It seems that `sleep x' with a high enough value of x between the timestamp 
> > and the snapshot remedies the problem. The interesting point is the choice 
> > of x. I was able to show that the problem occurs for x=0.299, but although I 
> > tried very hard, I could *not* provoke the problem with x=0.3. So, 300 
> > milliseconds seem to be the magic threshold.
> 
> OK, this verifies that the problem is caused by the implementation of filesystem 
> in the kernel. I would even call it a bug if you may create a snapshot that
> refers to unstable (unreliable) data.
> 

Re: refuse to update certain files upon extraction

* Message by -Lasse Kliemann- from Sun 2008-03-09:

> There was no error message (tried -vv, but not -debug). Some time passed 
> since, and I do not have those files anymore. But I found a way to reproduce 
> this, or at least something similar. How to do this is slightly complicated, 
> and I do not understand it fully myself, so I go right to the results. There 
> is a level 0 dump and a level 1 dump, and a file F that changed between the 
> dumps. If the level 1 dump is extracted with 'star -xpU', then the file F is 
> restored to the state it was when the dump was taken. However, if the two 
> dumps are extracted onto each other with 'star -xpU -restore', mysteriously F 
> is made a hardlink to some other file, and hence of course is not restored to 
> its correct state.
> 
> Now, the dumps are taken off from a Linux LVM filesystem snapshot. As you 
> know, I already discovered irregularities with those (but could not yet
> investigate it further satisfactorily due to time constraints). Would you 
> suggest that the above problem is caused by a faulty filesystem snapshot 
> implementation, or might this be a problem in star? You may inspect the 
> tarfiles if you wish, it's just about 2 MB; I uploaded them to 
> 
> http://unix.plastictree.net/tmp/20080309/dump0.tar
> http://unix.plastictree.net/tmp/20080309/dump1.tar
> 
> The file to look out for is `send-backup-test/supervise/pid'. It is made a 
> hardlink to `send-backup-test/log/supervise/pid' upon restore as described 
> above.

I've tracked this thing down further, and now I have a simple way to 
reproduce this, and it doesn't even involve snapshots. Attached is a small 
program rename.c. Assume that this program is available under the command 

Re: dealing with timestamp (in-)accuracy

* Message by -Lasse Kliemann- from Thu 2008-03-06:
> In create.c of star-1.5a87, line 281, it reads:
> 
>    } else if (dumplevel > 0) {
>       if (info->f_mtime > Newer.tv_sec) {
>          /* EMPTY */
>          ;
>       } else if (info->f_ctime > Newer.tv_sec) {
>          if (dumpmeta)
>             info->f_xftype = XT_META;
>       } else {
>          return (FALSE);
>       }
> 
> As far as I can see, this is the place where it is decided upon whether a 
> file will be included in the current dump, or if it may be assumed that it is 
> already included in a previous dump (and hence will not be included again). I 
> wonder whether the checks shouldn't be for greater *or* *equal*, i.e.:
> 
>       if (info->f_mtime >= Newer.tv_sec) {
>          /* EMPTY */
>          ;
>       } else if (info->f_ctime >= Newer.tv_sec) {

(...) 
> Further down, it reads:
> 
>    } else if (Newer.tv_sec && (Ctime ? info->f_ctime:info->f_mtime) <=
>                         Newer.tv_sec) {
> 

Re: segfaults with gcc 4.2.3

Mon, 3 Mar 2008 18:40:09 +0100, lasse-list-star-users wrote:

> Just for everyone's information: compiling star on newer gcc (I tested
> version 4.2.3 on Linux) with any optimization flags other than -O0 may
> result in segfaults in dump mode, like this:

How about gcc 4.3.0, which was released yesterday?

_______________________________________________
Star-users mailing list
Star-users <at> lists.berlios.de
https://lists.berlios.de/mailman/listinfo/star-users