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]

Re: gcc-2.95.2 crash when optimizing


Kurt Skauen <kurt.skauen@c2i.net> writes:

Hi again. I continue this little discussion with myself :)

 
> The conclution to all this must be that some spot in gcc
> relies on malloc() to return cleared memory :(

I was a bit quick there :( The problem seems to be that calloc()
in glibc-2.1.2 incorectly assumes that sbrk() will clear the
memory, even when re-aqiring previously free'd memory!

From glibc-2.1.2/malloc/malloc.c:

  MORECORE_CLEARS           (default 1)
     True (1) if the routine mapped to MORECORE zeroes out memory (which
     holds for sbrk).

Both the Irix (6.4) and Solaris (??) manpages say someting like this:

  Newly allocated space is set to zero. If, however, the same memory
  space is reallocated to the same process its contents are undefined.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The linux man page does not define it at all.
  
 
> It should be possible for the maintainers to reproduse
> this by inserting a memset( newmem, -1, size ) or someting
> similar in xmalloc(). 

If you are going to try this you must insert the memset() in
xcalloc() instead, which sounds like a less than great idea :)


> BTW: Is sbrk() supposed to return cleared memory?

It was not, but glibc-2.1.2 assumes it does!

Sorry for wasting your bandwith on this nonsence.

Guess I should run over to the glibc bug list and
waste some bandwith there instead :)

-- 
Kurt Skauen
Programmer at Funcom Oslo AS (http://www.funcom.com/)
Author of AltOS (http://altos.funcom.com/)


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