Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Overwriting Allocated Memory from malloc()

Reply
Thread Tools

Overwriting Allocated Memory from malloc()

 
 
tweak
Guest
Posts: n/a
 
      07-09-2004

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");
exit(1);
}

for ( int i; i < 255; i++ )
buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )
y++;
(void)printf("ptr is: %s\n", ptr);
free(ptr);

return 0;
}
 
Reply With Quote
 
 
 
 
Eric Amick
Guest
Posts: n/a
 
      07-09-2004
On Thu, 08 Jul 2004 18:22:16 -0700, tweak <(E-Mail Removed)> wrote:

>As far as I know, overwriting the allocated space
>from a call to malloc() results in undefined
>behavior.
>
>Any ideas why overwriting the dynamically
>assigned space doesn't cause a segmentation
>fault?


Because undefined behavior by definition can be anything at all. You
were lucky, nothing more.

--
Eric Amick
Columbia, MD
 
Reply With Quote
 
 
 
 
Lewis Bowers
Guest
Posts: n/a
 
      07-09-2004


tweak wrote:

> I have been messing around with buffers, and
> I found it peculiar that the code below will
> run without a segmentation fault.
>
> As far as I know, overwriting the allocated space
> from a call to malloc() results in undefined
> behavior.
>
> Any ideas why overwriting the dynamically
> assigned space doesn't cause a segmentation
> fault?


Why would you expect undefined behavior(UB) to cause seg fault?
To me, UB seems to suggest that anything can happen; good, bad, expected

or unexpected.


 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      07-09-2004
On Thu, 08 Jul 2004 18:22:16 -0700, tweak <(E-Mail Removed)>
wrote:

>
>I have been messing around with buffers, and
>I found it peculiar that the code below will
>run without a segmentation fault.
>
>As far as I know, overwriting the allocated space
>from a call to malloc() results in undefined
>behavior.
>
>Any ideas why overwriting the dynamically
>assigned space doesn't cause a segmentation
>fault?


Undefined behavior is not guaranteed to cause a segment fault. In its
most pernicious form, it appears to work properly until it can satisfy
one of Murphy's laws.

>
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>#include <errno.h>
>
>int
>main(void)
>{
>
> char *ptr = NULL;
> char buffer[256]; /* intentionally did not initialize */
> int y = 0;
>
> if ( ( ptr = malloc(1) ) == 0 ) {
> perror("malloc() problem");
> exit(1);
> }
>
> for ( int i; i < 255; i++ )
> buffer[i] = 'Z';
>
> while ( (ptr[y] = buffer[y]) != '\0' )
> y++;
> (void)printf("ptr is: %s\n", ptr);
> free(ptr);
>
> return 0;
>}




<<Remove the del for email>>
 
Reply With Quote
 
tweak
Guest
Posts: n/a
 
      07-09-2004
Barry Schwarz wrote:
> On Thu, 08 Jul 2004 18:22:16 -0700, tweak <(E-Mail Removed)>
> wrote:
>
>
>>I have been messing around with buffers, and
>>I found it peculiar that the code below will
>>run without a segmentation fault.
>>
>>As far as I know, overwriting the allocated space

>
>>from a call to malloc() results in undefined

>
>>behavior.
>>
>>Any ideas why overwriting the dynamically
>>assigned space doesn't cause a segmentation
>>fault?

>
>
> Undefined behavior is not guaranteed to cause a segment fault. In its
> most pernicious form, it appears to work properly until it can satisfy
> one of Murphy's laws.


I tried different sizes of the buffer array, and I was able to generate
a segmentation fault. Since the compiler tells me everything is okay,
and since the software appears to work, are there any audit tools to
check for problems like this one, where the compiler doesn't warn of
a potential problem (beyond just the malloc() ones listed in the FAQ)?

I'm sure you grep or use an equivalent tool in the many different
OS's we have. But are there any portable tools?

Of course, writing ISO C99 code that is portable is preferred, but you
can miss stuff as the number of lines of code and number of files increase.

Brian
 
Reply With Quote
 
Vijay Kumar R Zanvar
Guest
Posts: n/a
 
      07-09-2004

"tweak" <(E-Mail Removed)> wrote in message newsJpHc.787$rr.721@fed1read02...
> Barry Schwarz wrote:
> > On Thu, 08 Jul 2004 18:22:16 -0700, tweak <(E-Mail Removed)>
> > wrote:

[..]
> I tried different sizes of the buffer array, and I was able to generate
> a segmentation fault. Since the compiler tells me everything is okay,
> and since the software appears to work, are there any audit tools to
> check for problems like this one, where the compiler doesn't warn of
> a potential problem (beyond just the malloc() ones listed in the FAQ)?
>


lint may be helpful. See below.

> I'm sure you grep or use an equivalent tool in the many different
> OS's we have. But are there any portable tools?
>
> Of course, writing ISO C99 code that is portable is preferred, but you
> can miss stuff as the number of lines of code and number of files increase.
>
> Brian



> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> int
> main(void)
> {
>
> char *ptr = NULL;
> char buffer[256]; /* intentionally did not initialize */
> int y = 0;
>
> if ( ( ptr = malloc(1) ) == 0 ) {
> perror("malloc() problem");
> exit(1);
> }
>
> for ( int i; i < 255; i++ )


i is uninitialized. UB.

> buffer[i] = 'Z';
>
> while ( (ptr[y] = buffer[y]) != '\0' )
> y++;
> (void)printf("ptr is: %s\n", ptr);
> free(ptr);
>
> return 0;
> }


F:\>splint overflow.c
Splint 3.0.1.6 --- 11 Feb 2002

overflow2.c: (in function main)
overflow2.c(15,1: Unrecognized identifier: NULL
Identifier used in code has not been declared. (Use -unrecog to inhibit
warning)
overflow2.c(19,19): Unrecognized identifier: malloc
overflow2.c(20,10): Unrecognized identifier: perror
overflow2.c(21,10): Unrecognized identifier: exit
overflow2.c(27,15): Index of possibly null pointer ptr: ptr
A possibly null pointer is dereferenced. Value is either the result of a
function which may return null (in which case, code should check it is not
null), or a global, parameter or structure field declared with the null
qualifier. (Use -nullderef to inhibit warning)
overflow2.c(19,19): Storage ptr may become null
overflow2.c(27,24): Value buffer[] used before definition
An rvalue is used that may not be initialized to a value on some execution
path. (Use -usedef to inhibit warning)
overflow2.c(29,12): Unrecognized identifier: printf
overflow2.c(30,6): Unrecognized identifier: free

Finished checking --- 8 code warnings


 
Reply With Quote
 
tweak
Guest
Posts: n/a
 
      07-09-2004
Vijay Kumar R Zanvar wrote:
> "tweak" <(E-Mail Removed)> wrote in message newsJpHc.787$rr.721@fed1read02...
>
>>Barry Schwarz wrote:
>>
>>>On Thu, 08 Jul 2004 18:22:16 -0700, tweak <(E-Mail Removed)>
>>>wrote:

>
> [..]
>
>>I tried different sizes of the buffer array, and I was able to generate
>>a segmentation fault. Since the compiler tells me everything is okay,
>>and since the software appears to work, are there any audit tools to
>>check for problems like this one, where the compiler doesn't warn of
>>a potential problem (beyond just the malloc() ones listed in the FAQ)?
>>

>
>
> lint may be helpful. See below.


Thanks. I used google to find it. I will start using it tomorrow.
I also found a splint. I will look at them both when I have more
energy.


>
>
>>I'm sure you grep or use an equivalent tool in the many different
>>OS's we have. But are there any portable tools?
>>
>>Of course, writing ISO C99 code that is portable is preferred, but you
>>can miss stuff as the number of lines of code and number of files increase.
>>
>>Brian

>
>
>
>>#include <stdio.h>
>>#include <stdlib.h>
>>#include <string.h>
>>#include <errno.h>
>>
>>int
>>main(void)
>>{
>>
>> char *ptr = NULL;
>> char buffer[256]; /* intentionally did not initialize */
>> int y = 0;
>>
>> if ( ( ptr = malloc(1) ) == 0 ) {
>> perror("malloc() problem");
>> exit(1);
>> }
>>
>> for ( int i; i < 255; i++ )

>
>
> i is uninitialized. UB.


Good catch. My source code reads as : for (int i = 0; i < 255; i++).
I made a typo.

Also since malloc() returns a NULL pointer on failure, the line that
starts with if should read:

if ( ( ptr = malloc(1) ) == NULL ) {

to be consistent even though it's just a style thing.

Thanks,

Brian
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      07-09-2004
tweak <(E-Mail Removed)> wrote:

> > "tweak" <(E-Mail Removed)> wrote in message newsJpHc.787$rr.721@fed1read02...
> >> if ( ( ptr = malloc(1) ) == 0 ) {


> Also since malloc() returns a NULL pointer on failure,


No, it doesn't. It returns a null pointer. NULL is a macro, which
expands to a null pointer _constant_, and exists only in your source
code; a null pointer is an object, which exists during runtime.

> the line that starts with if should read:
>
> if ( ( ptr = malloc(1) ) == NULL ) {
>
> to be consistent even though it's just a style thing.


There's nothing consistent about it. The original is just as good, just
as clear, and just as proper C. The only way in which this version could
be more, rather than just as, consistent, is if you've used NULL
everywhere else in your code; but that is consistency with _yourself_,
not with C. C does not distinguish between those two versions; both must
work equally well.

Richard
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      07-09-2004
In 'comp.lang.c', Eric Amick <(E-Mail Removed)> wrote:

> On Thu, 08 Jul 2004 18:22:16 -0700, tweak <(E-Mail Removed)> wrote:
>
>>As far as I know, overwriting the allocated space
>>from a call to malloc() results in undefined
>>behavior.
>>
>>Any ideas why overwriting the dynamically
>>assigned space doesn't cause a segmentation
>>fault?

>
> Because undefined behavior by definition can be anything at all. You
> were lucky, nothing more.


I'd rather have said "you were unlucky".

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      07-09-2004
In 'comp.lang.c', tweak <(E-Mail Removed)> wrote:

> I have been messing around with buffers, and
> I found it peculiar that the code below will
> run without a segmentation fault.


May be it's correct, who knows ?

> As far as I know, overwriting the allocated space
> from a call to malloc() results in undefined
> behavior.


Yes.

> Any ideas why overwriting the dynamically
> assigned space doesn't cause a segmentation
> fault?


Why should do it ? An undefined behaviour in unpredictable. Anything may
happen, including a safe behaviour. Imagine you ask for 50 char. Some
implementation could give you the address of a 64 char block. You could write
at [50] to [63] safely.

The problem is that you don't know about the actual safe size. The C-language
only guarantees that the wanted size is safe. I know other implementations of
memory allocator (PSoS) where an additional parameter is used to return the
actual allocated size.

> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> int
> main(void)
> {
>
> char *ptr = NULL;
> char buffer[256]; /* intentionally did not initialize */
> int y = 0;
>
> if ( ( ptr = malloc(1) ) == 0 ) {


Should be '== NULL' to preserve reader's mental health.

> perror("malloc() problem");
> exit(1);


exit (EXIT_FAILURE);

for portability.

> }
>
> for ( int i; i < 255; i++ )


Warning, This construct only works in C99.

> buffer[i] = 'Z';
>
> while ( (ptr[y] = buffer[y]) != '\0' )


Of course, you are overwriting the array pointed by ptr, but you know it
already.

> y++;


Because 'buffer' was intentionally not initialized, there is no guarantee
that a 0 is present at [255].

> (void)printf("ptr is: %s\n", ptr);


Can be anything.

> free(ptr);
>
> return 0;
> }



--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Program layout in memory (is anything overwriting my static pointer?) simonl C Programming 41 10-10-2008 09:44 PM
A possible memory overwriting. jammie_linux@yahoo.com C Programming 9 11-08-2005 06:57 PM
How to check memory size allocated to JVM? Laura Heinzmann Java 1 02-16-2005 04:37 AM
Dynamically Allocated Memory vs. Statically allocated Memory csnerd@gmail.com C++ 5 12-09-2004 01:44 AM
Duplicate memory allocated by IndexedTriangleArray Duncan Java 0 07-21-2003 07:25 PM



Advertisments