http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-11
10:09:15 UTC ---
(In reply to comment #1)
> Apparently this happens inside the copying routine, but I'm not quite sure
> where exactly the problem is.
Well, that's simple. If one looks at the dump (for a scalar "a" to make it more
readable), one finds in __MAIN for "allocate(t2 :: x)":
if (y._data == 0B)
{
D.1558 = (integer(kind=8)) x._vptr->_size;
D.1559 = (void * restrict) __builtin_malloc (MAX_EXPR <D.1558, 1>);
D.1557 = (struct t *) D.1559;
y._data = D.1557;
}
x._vptr->_copy (x._data, y._data);
And in __copy_MAIN___t2:
D.1520 = *dst;
if (D.1520.a != 0B)
__builtin_free ((void *) D.1520.a);
Thus, if MALLOC returns a nullified data, "(y._data->a)" will be false and
everything is fine. However, if "y._data->a" contains random data, one tries to
free the memory for y._data->a, which leads to a crash.
Thus, it is not surprising that it worked for you as GLIBC by default returns
NULL memory. However, if one uses the environment variable
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
The memory returned by malloc will be prefilled by the bytes of MALLOC_PERTURB_
and the program will crash.
As also due to other reasons the memory might be uninitialized and valgrind
also complains, the bug should be fixed. Possibly such that that there is no
overhead (also not with Paul's (re)allocate patch.)
