Bug 728386 - [abrt] bash-4.1.7-4.fc14: _int_malloc: Process /bin/bash was killed by signal 11 (SIGSEGV)
Summary: [abrt] bash-4.1.7-4.fc14: _int_malloc: Process /bin/bash was killed by signal...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 14
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Roman Rakus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:618a3e8e8e130d9043a8dba0008...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-04 22:15 UTC by Nivag
Modified: 2014-01-13 00:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-04 22:34:01 UTC


Attachments (Terms of Use)
File: backtrace (159.00 KB, text/plain)
2011-08-04 22:15 UTC, Nivag
no flags Details

Description Nivag 2011-08-04 22:15:12 UTC
abrt version: 1.1.18
architecture: x86_64
Attached file: backtrace, 162811 bytes
cmdline: /bin/bash ./sample_min.sh
component: bash
Attached file: coredump, 21307392 bytes
crash_function: _int_malloc
executable: /bin/bash
kernel: 2.6.35.13-92.fc14.x86_64
package: bash-4.1.7-4.fc14
rating: 4
reason: Process /bin/bash was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
time: 1312494974
uid: 500

comment
-----
I was trying to debug the following bash script (which is a reduced example from a amuch bigger script, with added diagnostics), and it cause a core dump:

#!/bin/bash
#  name_value_min.sh

function padded_name_value
{
    VAR_NAME=$1
    VAR_DOLLAR="\$$VAR_NAME"
    VAR_VAL=$(eval "echo $VAR_DOLLAR")   
echo '1001'    
echo $FUNCNAME
echo '1002'    
echo $VAR_NAME
echo '1003'    
    padded_name_value VAR_NAME    
    padded_name_value 'VAR_NAME'     
    padded_name_value $VAR_NAME    
    padded_name_value "$VAR_NAME"
echo '1004' 
echo $VAR_DOLLAR
echo '1006'    
    padded_name_value VAR_VAL    
    padded_name_value 'VAR_VAL'     
    padded_name_value $VAR_VAL    
    padded_name_value "$VAR_VAL"
echo '1007'  
    PADDING_SIZE=30
    FORMAT="%${PADDING_SIZE}s=[%s]\n"
    printf $FORMAT $VAR_NAME "$VAR_VAL"
echo '1008'  
}

function file_exists
{
    VAR_NAME="$1"
    VAR_DOLLAR="\$$VAR_NAME"
    VAR_VAL=$(eval "echo $VAR_DOLLAR")
    MODE="$2"
echo '2001'    
echo $FUNCNAME
echo '2002'    
echo $VAR_NAME
echo '2003'    
    padded_name_value VAR_NAME    
    padded_name_value 'VAR_NAME'     
    padded_name_value $VAR_NAME    
    padded_name_value "$VAR_NAME"
echo '2004' 
echo $VAR_DOLLAR
echo '2006'    
    padded_name_value VAR_VAL    
    padded_name_value 'VAR_VAL'     
    padded_name_value $VAR_VAL    
    padded_name_value "$VAR_VAL"
echo '2007'  
}

JB_FILE=$0
echo '3001'    
padded_name_value JB_FILE
echo '3002'    
file_exists 'JB_FILE' 'r'
echo '3003'    
padded_name_value JB_FILE
echo '3004'    


############## further comment
In the 'production' script, the method 'padded_name_value' is used to print out formatted diagnostics, with the '=' lined up, but the method appears to fail when called within another method with strange results.  The above reduced script was an an attempt to investigate further...

             JB_SRC_DIR_PARENT=[/home/software/updates/jboss]
                    JB_SRC_DIR=[/home/software/updates/jboss/jboss-as-7.0.0.Final]

How to reproduce
-----
1. ran bash script
2.
3.

Comment 1 Nivag 2011-08-04 22:15:17 UTC
Created attachment 516797 [details]
File: backtrace

Comment 2 Nivag 2011-08-04 22:22:14 UTC
The sample output is from the production script, not the reduced example.

However, it does show how name value pairs should be displayed - except that the '=' signs would actually be lined up.

Comment 3 Nivag 2011-08-04 22:34:01 UTC
Hmm...

Reason for core dump is obvious: infinite recursion!

(Isn't hindsight wonderful...)


Note You need to log in before you can comment on or make changes to this bug.