bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Segfault in bash 3.0


From: Ben Cotterell
Subject: Segfault in bash 3.0
Date: Fri, 11 Nov 2005 23:58:09 +0000
User-agent: KMail/1.6.2

bash version 3.0 crashes with a segmentation fault when running this
script:

    #!/bin/bash
    # Running this script crashes bash version 3.0 (and 2.05b.0(1))

    function foo
    { 
        local w
        local c
        c=(${w[@]} and stuff)
        echo ${c[@]}
    }

    w=/tmp
    foo

I tried to be helpful and investigate the bug. Here is my fix:

--- variables.c 2005-11-11 23:40:53.288909032 +0000
+++ ../org/bash-3.0/variables.c 2004-07-04 18:57:26.000000000 +0100
@@ -1643,12 +1643,6 @@
         things like `x=4 local x'. */
       if (was_tmpvar)
         var_setvalue (new_var, savestring (tmp_value));
-      else
-        {
-          char *value = (char *)xmalloc (1); /* like do_assignment_internal 
*/
-          value[0] = '\0';
-          var_setvalue (new_var, value);
-        }
 
       new_var->attributes = exported_p (old_var) ? att_exported : 0;
     }

Discussion of fix follows:

The crash is caused directly by a NULL string turning up in a place
where the worst that was expected was an empty string. It's when we're
expanding the [@] expression that we hit the problem.

So there seem to be two ways to fix it:

1. Why is the string NULL, should it be empty? Make sure it's never
NULL.

This seems most likely to be the right fix. There's code in a few places
that does this kind of thing (do_assignment_internal and assign_in_env).

The problem only seems to be caused when a global variable is shadowed
by an uninitialized local, and then used in a [@] expression. 

The call to make_new_variable, in make_local_variable, variables.c: 1641
is where it gets set up. If we make sure value is an empty string at
this point, we should fix the problem.

This seems to work OK, and is the fix I've gone for.

2. Handle a NULL string in make_bare_word and make_word_flags.

This also works, and is low risk, although it could affect performance I
suppose... this code is probably on a lot more code paths.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]