Description of problem: 'ls' command ina directory with a large number of directories Version-Release number of selected component: bash-4.3.33-1.fc21 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: bash crash_function: xfree executable: /usr/bin/bash kernel: 3.17.8-300.fc21.x86_64 runlevel: N 3 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #6 xfree at xmalloc.c:148 #7 _rl_free_match_list at complete.c:1907 #8 rl_complete_internal at complete.c:2063 #9 _rl_dispatch_subseq at readline.c:879 #10 _rl_dispatch at readline.c:822 #11 readline_internal_char at readline.c:649 #12 readline_internal_charloop at readline.c:676 #13 readline_internal at readline.c:690 #14 e at readline.c:416 #15 yy_readline_get at ./parse.y:1455
Created attachment 982810 [details] File: backtrace
Created attachment 982811 [details] File: cgroup
Created attachment 982812 [details] File: core_backtrace
Created attachment 982813 [details] File: dso_list
Created attachment 982814 [details] File: environ
Created attachment 982815 [details] File: limits
Created attachment 982816 [details] File: maps
Created attachment 982817 [details] File: open_fds
Created attachment 982818 [details] File: proc_pid_status
Created attachment 982819 [details] File: var_log_messages
Can you reproduce it every time? Could you provide me with some numbers for that dir (how many subdirs..)? Thanks
The directory contains 6 files and 25712 subdirs. I can't reproduce the crash. I reviewed the content of $HOME/.bash_history in order to found the exact command but I found nothing distinct than usual. I tried 'ls', 'ls -sort', 'ls + tab' and 'ls + u + tab' for auto-completation, 'find . -name \*u\*', execute the previous commands as another user, ... and nothing. All runs fine :-( note: tests were done after PC reboot.
Hmm, that doesn't give me much to go on, looking at your /var/log tail, a core wasn't generated either... looking at the backtrace file, the crash was apparently caused by the readline part of bash, but still, too much info is optimized out. I'm going to have to close it for now, if you'll ever come across this again, feel free to reopen.
Another user experienced a similar problem: > su - root > ls /home/user1/dir_with_a_lot_of_subdirs/ + Tab + Ctrl-C reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: -bash crash_function: xfree executable: /usr/bin/bash kernel: 3.18.3-201.fc21.x86_64 package: bash-4.3.33-1.fc21 reason: bash killed by SIGABRT runlevel: N 3 type: CCpp uid: 0
Hi Ondrej, I reproduced the error. Seems that is the combination of large number of subdirs + command + Tab + Ctrl-C. I can't reproduce systematically, but if I repeat some times then crash.
Hey Gerard, unfortunately, I still can't reproduce it on my side. If you could generate a coredump and attach it, that would really help. Thanks
Hi Ondrej, I have reproduced the crash on a distinct machine (but same operating system). The error behaviour is slightly different, but triggered by the same procedure: command + tab + tab + ctrl-C I attached 3 coredumps. Commands used to recreate the environment: for i in $(seq 1 125712); do mktemp -d -p . -t XXXXXXXX done touch file1.txt touch file2.txt touch file3.txt touch file4.txt touch file5.txt Commands used to enable the coredump: ulimit -c unlimited ulimit -a echo "core.%e.%p" > /proc/sys/kernel/core_pattern Commands used to create the crashes: more + tab + tab + ctrl-c ls + tab + tab + ctrl-c Regards, Gerard
Created attachment 1003379 [details] coredumps 2015/03/18 coredumps created on 2015-03-18.
The coredumps didn't tell me much :/ though some things have been fixed in bash since -33.1. Can you still reproduce this on a fully-updated F22?
I made some attempts and I cannot reproduce the bug in Fedora-22. Seems that the latest version has solved the bug. Good!
Glad to hear that! I'll be closing this for now, feel free to reopen if you come across this again.