Description of problem: Was simply trying to move a script from one directory to another. The script in question will be attached to this BZ, Version-Release number of selected component: bash-4.2.45-4.fc20 Additional info: reporter: libreport-2.2.0 backtrace_rating: 4 cmdline: /bin/bash crash_function: xmalloc executable: /usr/bin/bash kernel: 3.13.6-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #2 xmalloc at xmalloc.c:112 #3 string_extract_double_quoted at subst.c:785 #4 expand_word_internal at subst.c:8267 #5 shell_expand_word_list at subst.c:9245 #6 expand_word_list_internal at subst.c:9362 #7 expand_words_no_vars at subst.c:8993 #8 execute_for_command at execute_cmd.c:2453 #9 execute_command_internal at execute_cmd.c:815 #10 execute_command at execute_cmd.c:386 #11 execute_connection at execute_cmd.c:2336
Created attachment 878832 [details] File: backtrace
Created attachment 878833 [details] File: cgroup
Created attachment 878834 [details] File: core_backtrace
Created attachment 878835 [details] File: dso_list
Created attachment 878836 [details] File: environ
Created attachment 878837 [details] File: exploitable
Created attachment 878838 [details] File: limits
Created attachment 878839 [details] File: maps
Created attachment 878840 [details] File: open_fds
Created attachment 878841 [details] File: proc_pid_status
Created attachment 878842 [details] File: var_log_messages
Created attachment 878843 [details] The script I was trying to move This is the simple script I was attempting to move from /home/dan/ to /home/dan/aws/ - I tried two more times after this crash, and it happened every time.
I can repeat this ad infinitum with my user account. I can't move any files at all. As root, there are no issues. selinux is turned off. I switched to /bin/sh as the shell, and it has no issues moving files. It is just bash with my user account. I will reboot and see if that clears it up (I need to reboot anyhow - a lot of updates to apply).
Three reboots later and a new kernel, it is still happening. But it appears to be something in my profile - when I switch to /bin/sh, which is a symlink to /bin/bash, it bypasses my .bashrc .bash_profile files and works just fine.
Hi and thanks for the report. Could you please attach the contents of your .bashrc and .bash_profile? From the backtrace it seems xmalloc() is passed a legal value. Also, are you able to reproduce this with bash-4.3 in rawhide? Thanks.
Sorry this took so long to get back to. I want to confirm that this is still happening in bash-4.2.47-2.fc20.x86_64. I have not tried in rawhide, as rawhide will not run on my laptop due to bugs in the Nouveau driver. Since both files you requested to see are terrbly short, I'll just paste them instead of attaching. [dan@g55 ~]$ cat .bashrc # .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # Uncomment the following line if you don't like systemctl's auto-paging feature: # export SYSTEMD_PAGER= # User specific aliases and functions alias shop='ssh -X dan.1.51' alias shopr='ssh -X root.1.51' function mv () { for last; do true; done if [[ ! -e $last ]]; then mkdir -p $last fi mv $@ } [dan@g55 ~]$ cat .bash_profile # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH [dan@g55 ~]$ And now that I've pasted those, I see the problem - I was trying to create a function to move recursively. The function didn't work, and I forgot all about it. I removed that function from .bashrc, and solved the problem. There isn't a bug in bash - the bug was all mine. Sorry about that.
No problem, this still leads to a bug in bash - one that I'm already aware of from another ABRT report, but still, I think I should explain it. You see, bash is able to detect recursive functions, but only if you specififed the function as function mv { #code } OR mv () { #code }. Now this -> "function mv () {#code}" is not POSIX-ly correct (although a very common way to write a shell function), and for some reason bash fails to catch the inf. recursion and lets it smash its stack. This also happens in the very newest version of bash :( .