>> I assume this is a valgrind false positive.
>
>That possible. However, the assertion that causes the abort, is part of
>the malloc.c version (line 934) that ships with bash. I guess that the
>issue is caused by the fact that bash uses it's own malloc.c, which
>seems to be incompatible with valgrind.
The immediate cause of this error (which is indeed a false positive) is
that Valgrind replaces calls to functions named "malloc" and "free" with
its own memory management functions, but Bash's "free" (from
lib/malloc/malloc.c) is renamed to "sh_xfree" by xmalloc.h. So memory
allocations from Bash call Valgrind's malloc(), then eventually pass
that pointer to Bash's custom free(), which naturally gets confused
because the pointer wasn't returned from the custom malloc() in the same
file.
That said, defining an externally visible function named malloc() causes
undefined behavior according to my reading of C99 7.1.3:
"All identifiers with external linkage in any of the following
subclauses [...] are always reserved for use as identifiers with
external linkage.
[...]
If a program declares or defines an identifier in a context in which it
is reserved (other than as allowed by 7.1.4), or defines a reserved
identifier as a macro name, the behavior is undefined."
So an argument could be made that Bash should rename its malloc() and
realloc() similarly to free(), which would also avoid this false
positive.
(Strictly speaking, even the renaming of "free" to "sh_xfree" in
xmalloc.h results in undefined behavior by the above rule, but that at
least is resolved at compilation time, and I presume there are no
real-world build environments in which that renaming causes a problem.)
--Andrew Church
http://achurch.org/
