Hm, that's a mouthful.
Running bash 3.1.17.
$ bash -c 'foo=""; (( ${foo:1} < 10 ))'
bash: Xl: < 10 : syntax error: operand expected (error token is "< 10 ")
^^^
The characters indicated by carets above differ from run to run
depending on memory usage. Obviously, this indicates that bash is
spewing the contents of freed memory.
The freed string being read into the error message is (global)
this_command_name (evalerror in expr.c). Putting a watch in gdb on
this_command_name indicates that the point it is freed is subst.c line
6047:
/* If this is a substring spec, process it and add the result. */
if (want_substring)
{
temp1 = parameter_brace_substring (name, temp, value, quoted);
FREE (name);
FREE (value);
FREE (temp);
On going into parameter_brace_substring(), parameter_brace_substring
assigns its first argument to this_command_name. When it is freed after
exit, this_command_name points to freed memory.
Simplest fix would probably be to have parameter_brace_substring assign
its return value to this_command_name before exit, to ensure that
this_command_name always points to valid memory.
Patch attached.
Ed Catmur
--- bash-3.1/subst.c 2006/05/24 06:24:44 1.1
+++ bash-3.1/subst.c 2006/05/24 06:25:15
@@ -5524,6 +5524,7 @@ parameter_brace_substring (varname, valu
temp = (char *)NULL;
}
+ this_command_name = temp;
return temp;
}
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
