Reg. Charney wrote: > The result of this command is: > > [EMAIL PROTECTED] ~]# 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: > > [EMAIL PROTECTED] ~]# 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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
