Re: Segment fault rm corrupt files
On Tue, July 17, 2007 3:46 am, Bob Proulx wrote: Reg. Charney wrote: On a number of occasions, Konqueror has crashed and produced a file named something like: /tmp/kde-$USER/konqueror-crash-XX.log However, the file has an unknown type, size, and permissions. This makes no sense in the context of Unix filesystems. Please run the following command and post the output to the mailing list. You may need to adjust the file globs to match. ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log 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 reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-SQil1b.log However, this was run after I somehow deleted the invalid files since I could not reboot without eliminating these invalid files. This is a contradiction to the original bug report. 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. Because I needed to delete the invalid files, I can not show you exactly what I had. However, 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 That will show us the file type, size and permissions. Or it will have an error which will also be informative. Again, the ls command at the time could not tell me this. As part of the /etc/rc.sysinit file, I have a rm command of the form: rm -rf /tmp/kde-$USER/* Typically systems will purge the contents of /tmp on a reboot. I think Fedora does this but can't check at the moment. In which case the above command is not needed. Regardless of that the $USER is an environment variable. Inside of the /etc/rc.sysinit script that will almost certainly be root. I don't think this will match the user that was actually running konqueror at the moment that the core file was created. Therefore it will be very unlikely to actually match any files. Actually, the crash logs are related to the user using kde at the time of failure. Thus, the subdirectory is named kde-reg where I was logged in as user 'reg'. 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. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segment fault rm corrupt files
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: [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 reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log -rw--- 1 reg reg0 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 Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Segment fault rm corrupt files
I am running Fedora Core 6: Linux regmac-fc6 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 18:24:12 EDT 2007 i686 i686 i386 GNU/Linux On a number of occasions, Konqueror has crashed and produced a file named something like: /tmp/kde-$USER/konqueror-crash-XX.log However, the file has an unknown type, size, and permissions. As part of the /etc/rc.sysinit file, I have a rm command of the form: rm -rf /tmp/kde-$USER/* 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)). In trying to solved this problem, I had run fsck a number of times, with no complaint from the fsck utility, even though the above mentioned files had invalid type(s). Any attempt to mv or cp fhese file raised fstat errors. Reg. Charney ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug in sort v5.2.1
I believe that sort in coreutils v5.2.1 has a basic bug in it - it seems to treat the period (.) as a non-existant character. Here is an example: $cat sample a.z ab.a a.c $sort sample ab.a a.c a.z This would be correct if we were to ignore the periods - the sort order would be aba, ac, az. I believe the order should be a.c, a.z, ab.a Reg. Charney ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
