GCC/Malloc bug? Help!

GCC/Malloc bug? Help!

Post by Cruden Charles » Thu, 02 Jun 1994 04:12:14



Hi.  I'm having a few strange problems with malloc on a compile of a program I
wrote.

Basically what's happening is malloc is causing a segmentation fault.  The code
I wrote (and rewrote 4 different ways) passes in a size for a character array
(a size below 20, usually in the region of 8 to 10) to malloc, calling it as
array = (char *) malloc (strlen(s));
where is s another string I want to copy into the array.  Using gdb, I traced
the program crash back and found that the size was being passed in correctly
to malloc from the program, but between __gnu_malloc and malloc.c, the size
got changed and the actual malloc.c malloc is being given a size of 0.  I don't
know for sure if this is the reason it crashes, but it looks suspicious.

Interestingly enough, the same thing happens with four different versions of
the same code, some using new instead of malloc, trying it as a linked list,
trying it as a continually changing array, everything.  It always crashes.

I have check the memory available each time.  While there isn't always much
actual memory free, there's plenty of virtual memory.  (32M total).

I have tried playing with different versions of the kernel I have lying around,
and different versions of the C libraries.  Neither of these changes have done
anything.  I'm currently working with kernel version 1.1.0, gcc 2.5.8 and the
library versions 4.5.21 or 4.5.26.  Any help would be greatly appreciated!

Thanks!

Charles Cruden

--
C.Cruden                                               (The llamas are coming!)
------                                                 (The llamas are coming!)
"God help us all... we're in the hands of engineers."
        - Ian Malcolm in the movie 'Jurassic Park'

 
 
 

GCC/Malloc bug? Help!

Post by Steven Buytae » Thu, 02 Jun 1994 17:07:16



: Basically what's happening is malloc is causing a segmentation fault.  The code
: I wrote (and rewrote 4 different ways) passes in a size for a character array
: (a size below 20, usually in the region of 8 to 10) to malloc, calling it as
: array = (char *) malloc (strlen(s));
: where is s another string I want to copy into the array.  Using gdb, I traced
: the program crash back and found that the size was being passed in correctly
: to malloc from the program, but between __gnu_malloc and malloc.c, the size
: got changed and the actual malloc.c malloc is being given a size of 0.  I don't
: know for sure if this is the reason it crashes, but it looks suspicious.

  As Hal Brooks pointed out already, probably the fact that
  you forgot to allocate 1 more character for the \0
  causes the SIGSEGV violation.

  The fact that you see malloc changing the size is probably
  due too the fact that the gnu malloc uses size classes
  to allocate memory. If you request memory, there is always
  a small overhead for a header and then your requested size
  is added to that. The result of that sum is rounded to the
  next power of 2. Asking malloc for 0 bytes, should return
  you the smallest bin size bytes and not 0 bytes. In fact,
  if you want that malloc(0) returns NULL, you should
  have the MALLOC_0_RETURNS_NULL defined in your source code.

  First thing to fix, try 'array = (char *)malloc(strlen(s)+1)'.

  Stef

--
Steven Buytaert



        'Imagination is more important then knowledge.'
                        (A. Einstein)

 
 
 

GCC/Malloc bug? Help!

Post by Cruden Charles » Fri, 03 Jun 1994 04:18:07



Quote:>Hi.  I'm having a few strange problems with malloc on a compile of a program I
>wrote.
>Basically what's happening is malloc is causing a segmentation fault.  The code
>I wrote (and rewrote 4 different ways) passes in a size for a character array
>(a size below 20, usually in the region of 8 to 10) to malloc, calling it as
>array = (char *) malloc (strlen(s));

OK, bad form to follow up your own article, but I'm getting a lot of replies
(much apprciated) which unfortunately caught on to a mistake I made typing in
the article.  I know I made a mistake in the malloc call, and that I should
have written
array = (char *) malloc (strlen(s) +1);
That's in my code.  Unfortunately, the malloc call still fails.
To make the point: I'm never actually able to strcpy the string into array,
because malloc causes a SIGSEGV.

Quote:>where is s another string I want to copy into the array.  Using gdb, I traced
>the program crash back and found that the size was being passed in correctly
>to malloc from the program, but between __gnu_malloc and malloc.c, the size
>got changed and the actual malloc.c malloc is being given a size of 0.  I don't
>know for sure if this is the reason it crashes, but it looks suspicious.
>Interestingly enough, the same thing happens with four different versions of
>the same code, some using new instead of malloc, trying it as a linked list,
>trying it as a continually changing array, everything.  It always crashes.
>I have check the memory available each time.  While there isn't always much
>actual memory free, there's plenty of virtual memory.  (32M total).
>I have tried playing with different versions of the kernel I have lying around,
>and different versions of the C libraries.  Neither of these changes have done
>anything.  I'm currently working with kernel version 1.1.0, gcc 2.5.8 and the
>library versions 4.5.21 or 4.5.26.  Any help would be greatly appreciated!
>Thanks!
>Charles Cruden
>--
>C.Cruden                                           (The llamas are coming!)
>------                                                     (The llamas are coming!)
>"God help us all... we're in the hands of engineers."
>    - Ian Malcolm in the movie 'Jurassic Park'

--
C.Cruden                                               (The llamas are coming!)
------                                                 (The llamas are coming!)
"God help us all... we're in the hands of engineers."
        - Ian Malcolm in the movie 'Jurassic Park'
 
 
 

GCC/Malloc bug? Help!

Post by Cruden Charles » Fri, 03 Jun 1994 07:14:19


Well, I found my bug.  I was attempting to free some unintialized pointers, and
this was causing a corruption of the stack.  Once I initialized the pointers to
NULL and made a check before freeing a pointer, the program worked happily.

Thanks to all that replied!

A description of the problem I was having follows, for reference's sake.



>>Hi.  I'm having a few strange problems with malloc on a compile of a program I
>>wrote.
>>Basically what's happening is malloc is causing a segmentation fault.  The code
>>I wrote (and rewrote 4 different ways) passes in a size for a character array
>>(a size below 20, usually in the region of 8 to 10) to malloc, calling it as
>>array = (char *) malloc (strlen(s));
>OK, bad form to follow up your own article, but I'm getting a lot of replies
>(much apprciated) which unfortunately caught on to a mistake I made typing in
>the article.  I know I made a mistake in the malloc call, and that I should
>have written
>array = (char *) malloc (strlen(s) +1);
>That's in my code.  Unfortunately, the malloc call still fails.
>To make the point: I'm never actually able to strcpy the string into array,
>because malloc causes a SIGSEGV.
>>where is s another string I want to copy into the array.  Using gdb, I traced
>>the program crash back and found that the size was being passed in correctly
>>to malloc from the program, but between __gnu_malloc and malloc.c, the size
>>got changed and the actual malloc.c malloc is being given a size of 0.  I don't
>>know for sure if this is the reason it crashes, but it looks suspicious.
>>Interestingly enough, the same thing happens with four different versions of
>>the same code, some using new instead of malloc, trying it as a linked list,
>>trying it as a continually changing array, everything.  It always crashes.
>>I have check the memory available each time.  While there isn't always much
>>actual memory free, there's plenty of virtual memory.  (32M total).
>>I have tried playing with different versions of the kernel I have lying around,
>>and different versions of the C libraries.  Neither of these changes have done
>>anything.  I'm currently working with kernel version 1.1.0, gcc 2.5.8 and the
>>library versions 4.5.21 or 4.5.26.  Any help would be greatly appreciated!
>>Thanks!
>>Charles Cruden
>>--
>>C.Cruden                                               (The llamas are coming!)
>>------                                                 (The llamas are coming!)
>>"God help us all... we're in the hands of engineers."
>>        - Ian Malcolm in the movie 'Jurassic Park'
>--
>C.Cruden                                           (The llamas are coming!)
>------                                                     (The llamas are coming!)
>"God help us all... we're in the hands of engineers."
>    - Ian Malcolm in the movie 'Jurassic Park'

--
C.Cruden                                               (The llamas are coming!)
------                                                 (The llamas are coming!)
"God help us all... we're in the hands of engineers."
        - Ian Malcolm in the movie 'Jurassic Park'
 
 
 

GCC/Malloc bug? Help!

Post by Geoff Newt » Fri, 03 Jun 1994 14:37:57



Quote:>Ce brave Cruden Charles E ecrit:
>> array = (char *) malloc (strlen(s));
>> where is s another string I want to copy into the array.  Using gdb, I traced
>Then you have to malloc( strlen(s) + 1 ).
>strlen does not count the leading '\0'; but your strcpy will try to write
>one, and you'll get a segmentation fault.
>(Or better, use sizeof(char) instead of 1)

Or better, use strdup() if linux supports it (and you just want a copy of
the string).

--

(-|    |                                                         | /     *
       |                                                         | \_.-._/
       | "It works for me"                                       |      v

 
 
 

1. sbrk, malloc and gcc (2.6.0) in SunOS 4.1.3

  I am working on a program for my OS class and it invloves calling
sbrk(0) after malloc(). According to the "The design and implementation
of 4.3BSD UNIX Operating System," malloc calls sbrk for to allocate
memory. However in Sun's man page of sbrk it says

WARNINGS
     Programs combining the brk() and  sbrk()  system  calls  and
     malloc()  will not work.  Many library routines use malloc()
     internally, so use brk() and sbrk() only when you know  that
     malloc() definitely will not be used by any library routine.

But in the man page of malloc:

     ... When there is no suitable  space  already  free, the
     allocation routines call sbrk() (see brk(2)) to get more memory
     from the system...

As some experiments:

sbrk(0);
malloc(2000);
sbrk(0);

The return values of the function are different while compiling
with gcc and Sun cc (on a Sparc 10 with 256 MB of RAM).

gcc:
  sbrk 114504
  sbrk 114504
Sun cc:
  sbrk 16600
  sbrk 28896

So, first of my questions is that which of the man page is correct? Can I use
sbrk with malloc? Second, why cc and gcc give different answers? Third, where
can I find more information about Sun's implementation of these system calls
and library functions?

Thanks in advance.

--
Ta-Wei "David" Li
UNIX Consultant, University of Southern California
Member, League for Programming Freedom
"Innovate, don't litigate."

2. Stream benchmarks for VIA Apollo 133 motherboards

3. malloc in Aix xlC and GCC ?

4. Isolinux and NT install cd

5. bugs in malloc?

6. traffic logging

7. no malloc in gcc?

8. COM/CORBA equivalent

9. Use __attribute__((malloc)) for gcc 3.2

10. malloc, gcc-2.6.3, li

11. bug in glibc (malloc)

12. gcc, malloc, segmentation fault

13. malloc-bug in libc?