Bug 1035273

Summary: [abrt] bash-4.2.45-1.fc19: __gconv_transform_utf8_internal: Process /usr/bin/bash was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Valentin Bajrami <valentin.bajrami>
Component: bashAssignee: Ondrej Oprala <ooprala>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: admiller, ooprala, ovasik, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/021f3265ba250510bc2637d655b0876d0b735f6e
Whiteboard: abrt_hash:b40700008007dd1456c6ebdf8f7fd2048f8aa738
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-27 13:12:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Valentin Bajrami 2013-11-27 12:33:33 UTC
Description of problem:
By entering:  function cd() { cd "$@" && pushd "$@"; }; cd /home/${USER}

Version-Release number of selected component:
bash-4.2.45-1.fc19

Additional info:
reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        bash
crash_function: __gconv_transform_utf8_internal
executable:     /usr/bin/bash
kernel:         3.11.9-200.fc19.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 __gconv_transform_utf8_internal at ../iconv/skeleton.c:394
 #1 __mbrtowc at mbrtowc.c:85
 #2 mbrlen at /usr/include/wchar.h:402
 #3 string_extract_double_quoted at subst.c:823
 #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 at subst.c:8984
 #8 execute_simple_command at execute_cmd.c:3787
 #9 execute_command_internal at execute_cmd.c:747

Comment 1 Valentin Bajrami 2013-11-27 12:33:42 UTC
Created attachment 829688 [details]
File: backtrace

Comment 2 Valentin Bajrami 2013-11-27 12:33:45 UTC
Created attachment 829689 [details]
File: cgroup

Comment 3 Valentin Bajrami 2013-11-27 12:33:50 UTC
Created attachment 829690 [details]
File: core_backtrace

Comment 4 Valentin Bajrami 2013-11-27 12:33:56 UTC
Created attachment 829691 [details]
File: dso_list

Comment 5 Valentin Bajrami 2013-11-27 12:33:59 UTC
Created attachment 829692 [details]
File: environ

Comment 6 Valentin Bajrami 2013-11-27 12:34:02 UTC
Created attachment 829693 [details]
File: exploitable

Comment 7 Valentin Bajrami 2013-11-27 12:34:06 UTC
Created attachment 829694 [details]
File: limits

Comment 8 Valentin Bajrami 2013-11-27 12:34:09 UTC
Created attachment 829695 [details]
File: maps

Comment 9 Valentin Bajrami 2013-11-27 12:34:13 UTC
Created attachment 829696 [details]
File: open_fds

Comment 10 Valentin Bajrami 2013-11-27 12:34:16 UTC
Created attachment 829697 [details]
File: proc_pid_status

Comment 11 Valentin Bajrami 2013-11-27 12:34:19 UTC
Created attachment 829698 [details]
File: var_log_messages

Comment 12 Ondrej Oprala 2014-04-01 14:16:39 UTC
This is an ALMOST intended behaviour since the command "function foo () { ; }" is not posixly correct.

The correct form is either
"function foo { ; }"
OR
"foo () { ; }".

Both have slightly different behaviour,
but function foo () is so common that bash doesn't emit any warnings.
With the correct syntax, you would get:
"cd: maximum nested function level reached".

However, letting bash get SIGSEGV-ed, even with a non 100% posix-compliant shell script is a tiny bit extreme. What bash does exactly is smashing it's own stack by infinite recursion. I'll talk to upstream about this.

Thank you for the report.

Comment 13 Ondrej Oprala 2014-05-27 13:12:37 UTC
The offical upstream statement is that this works as intended. You can set the FUNCNEST environment variable to control the maximum recursion depth. However, stack size is still the hard limit, setting FUNCNEST doesn't ensure you'll be able to recurse as deeply as you'd like.