Re: Segment fault rm corrupt files

[Bob Proulx]

Reg. Charney wrote:
> The result of this command is:
> 
> address@hidden ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log
> drwx------ 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg
> -rw------- 1 reg reg    0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log
> -rw------- 1 reg reg    0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-SQil1b.log

Of course now with new files those look fine.  :-(

> The exact command that raised the segmentation fault was:
> rm -rf /tmp/kde-*
> Thus, the error may have been in the glob expansion, not in the rm command.

You might want to scan through your system logs and see if any
filesystem errors are logged there.  It appears that you were having
some filesystem related issues and perhaps there will be a clue left
behind about it there.

Segmentation violations are always bugs.  The problem is determining
the root cause of the bug.  Here it could be in the glob expansion or
in system added patches.  Because the rm command is fairly simple I am
in a little bit of disbelief that the problem is there but it could be.

> the following was the output I that I recall I received with the ls
> command:
> 
> address@hidden ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log
> drwx------ 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg
> ?--------- ? reg reg    ? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-XYwuxw.log
> ?--------- ? reg reg    ? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-STuxyz.log

This appears to indicate that the stat calls from ls to the kernel
requesting filesystem information failed.  The ls command reported the
information that it had available.  for the fields that it did not
have information it reported a '?'.

If the stat calls were failing then that would indicate a filesystem
problem and is why I think there may be errors logged to the system
log file usually /var/log/syslog or /var/log/messages or some such
system dependent location.

> Again, the ls command at the time could not tell me this.

Oh well.

> >> Because the type of these crash files are unknown, the rm command fails
> >>  with a segment fault on my Intel IA86 machine (a MacBook running
> >> Parallels Fedora Core 6 Linux under Mac OS X (10.4)).
> >
> > It would be good if you could show us the exact output.
> 
> I wish I could show this now, but the system was not in a state then that
> I could do this.

The reason I said that was because saying "the type of the files are
unknown" did not make sense to me since unix-like filesystems do not
have file types (in the same way that older filesystems had file
types).  At that point I was stuck.  But now with the additional
information about the ls listing we now know that there were failures
reported by the filesystem in response to the stat kernel filesystem
calls.  That is obviously not good.  But it probably not a bug in
coreutils, which is good for us on the coreutils list but worse for
you.

About all of the advice I can offer is to keep an eye on the
filesystem and see if the problem returns.  If the problem does return
then try running 'strace' and saving the output.

  strace -o /tmp/strace.out ls -ld /path/to/file

The strace will show the system calls and return values.  If stat
calls are failing this should show the information for those failures.

Good luck!

Bob