Version-Release number of selected component: coreutils-8.15-9.fc17 Additional info: libreport version: 2.0.18 abrt_version: 2.0.18 backtrace_rating: 4 cmdline: du -sh -sh 6e56p56v.default/ crash_function: leave_dir kernel: 3.6.10-2.fc17.x86_64 truncated backtrace: :Thread no. 1 (4 frames) : #2 leave_dir at fts-cycle.c:136 : #4 fts_build at fts.c:1329 : #5 fts_read at fts.c:909 : #6 du_files at du.c:592
Created attachment 669025 [details] File: core_backtrace
Created attachment 669026 [details] File: environ
Created attachment 669027 [details] File: backtrace
Created attachment 669028 [details] File: limits
Created attachment 669029 [details] File: cgroup
Created attachment 669030 [details] File: smolt_data
Created attachment 669031 [details] File: executable
Created attachment 669032 [details] File: maps
Created attachment 669033 [details] File: dso_list
Created attachment 669034 [details] File: proc_pid_status
Created attachment 669035 [details] File: open_fds
Created attachment 669036 [details] File: var_log_messages
The "dued" folder was stored onto a NTFS partition (via a simlink). The Windows OS "managing this folder" had not been shutdown but was only hibernating. The SMS file/folder is generated via an Android app name SMS Backup+ (https://play.google.com/store/apps/details?id=com.zegoggles.smssync&hl=fr). Hope this help.
Thanks for report and additional information, this crash was due to intentional abort after failure of hash_delete() gnulib function. Abort is not nice, but safe way of program exit. hash_delete() function can fail only in the case that hash is not found in the hash table. As many values in the backtrace are optimized out, the only way to find the culprit(and probably make exit more "user friendly") is to reproduce the issue. Are you able to reproduce the issue all the time or it was just once time crash?
Hi, Yes the bug is reproducible, I still get a core dump each time I du-sh the given directory. $ echo $? 134 How can I give you more helpful information about the bug?
There is a FTS_DEBUG condition in the gnulib sources, which serves for debugging such issues. But this will need recompilation from sources with FTS_DEBUG defined at the time of recompilation and will give me more information about the crash order. I probably won't be able to reproduce the scenario on my machine (I don't have dual boot with Windows...). If you want to prevent these crashes, you may probably exclude listing for the specific filesystem used by directory causing these issues (by --exclude-type=FSTYPE/-x FSTYPE). Maybe I can reproduce your scenario with using the filesystem type you are using - could you please tell me what is the fstype of the faulty directory? (you can get this info e.g. from /etc/mtab)
Hi. Happy new year! ;) Here is asking informations: 18:51:02 rflores@urgi240:Profiles$ ls -la ~/|grep thunderbird lrwxrwxrwx. 1 rflores rflores 64 14 oct. 15:25 .thunderbird -> /run/media/rflores/OS/Users/rflores/Application Data/Thunderbird 18:51:19 rflores@urgi240:Profiles$ cat /etc/mtab|grep OS /dev/sda3 /run/media/rflores/OS fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0 I got git master version for coreutil from gnu site. I launched bootstrap script, configure, make and make check successfully. But as I'm not at ease with C language and similar (neither its compilation), I don't know where should I set FTS_DEBUG correctly. Need help. o/
Happy new year too! :) This command should enable it: make CFLAGS="$CFLAGS -DFTS_DEBUG" - but it seems to be broken anyway - it seems http://old.nabble.com/-PATCH--fgetcwd%3A-new-module-tt32122124.html#a32122124 was never applied to upstream git and getcwdat.h module is not part of gnulib so the compilation just fails. I'll try to make a koji scratch build with FTS_DEBUG enabled for you (hopefully this week :) ).
Ok I'll wait for your binary. Thanks.
Testing package available at http://koji.fedoraproject.org/koji/taskinfo?taskID=4838646 ... you can use du ---debug for getting even more info... Please attach the log here once checked...
(unpack just du binary from the rpm, as the fts debug output may influence other commands as well)
Created attachment 672434 [details] DU log with ---debug option leading to core dump crash Here is the DU log with ---debug option leading to core dump crash. I used du binary (usr/bin/du) extracted from http://kojipkgs.fedoraproject.org//work/tasks/8647/4838647/coreutils-8.15-9.fc17.x86_64.rpm Hope this helps.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't want to lose this from the sight, although most likely this is fuse filesystem issue, it would be good to investigate that. As it is on the longterm todo list, adding FutureFeature and moving to Rawhide, to prevent EOL closing.
*** Bug 996756 has been marked as a duplicate of this bug. ***
I believe this bug has been fixed by the following upstream commit: http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=60af6a36