Re: Segment fault rm corrupt files

[Reg. Charney]

Hi Bob,

You are probably correct about file system corruption. I found a large
number of the following type of errors:

/var/log/messages.3:Jun 23 23:14:49 localhost kernel: EXT3-fs error
(device dm-0): ext3_free_blocks: Freeing blocks not in datazone - block =
1315991916, count = 1
/var/log/messages.3:Jun 23 23:14:49 localhost kernel: EXT3-fs error
(device dm-0): ext3_free_blocks_sb: bit already cleared for block 647337

I had not rebooted for a long time, so the corrupted files were not
detected until long after the errors occurred.

Again, thanks,

Reg.

On Tue, July 17, 2007 4:09 pm, Bob Proulx wrote:
> 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
>
>
>