This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***



------- Comment #8 from hainque at adacore dot com  2006-01-03 16:25 -------
Subject: Re:  FAIL:   a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***

charlet at adacore dot com wrote:
> Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment...

 Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT.

> Is it really the case that the C headers mandate an alignment of 16 for this
> type which is not guaranteed by malloc ?

 IIUC, it asks for a 16 bytes alignment consciously knowing that it likely
 won't get it in terms of objects' _addresses_. Now the request will
 still impact component _offsets_ within records (make them multiple
 of 16), as Dave points out, and not matching it in Ada might indeed
 cause various troubles.

 The big difference between Ada and C here is that the alignment must
 also be obeyed for objects addresses in Ada, which is why the
 allocator return address is rounded up (together with the size
 argument).

> > If ada is going to align malloc'd pointers, then it should keep track
> > of the adjustment or the original pointer so that the memory can be
> > freed using the original pointer.
> 
> Right, and this is a non trivial task, hence my previous comment.

 Right. Preliminary attempts at fixing this a while ago made it necessary
 to touch expand_expr and is_alignin_offset, fairly deep in the back end.

 Will look it up again.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]