By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,743 Members | 1,018 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,743 IT Pros & Developers. It's quick & easy.

malloc question - what happens when chunk gets free?

P: n/a
Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}

Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb

And run it under degugger:
[piotr::18:49:31]$ gdb 1
GNU gdb 6.0-debian
(...)
(gdb) l
(...)
7 strcpy(b, "BBB");
8 strcpy(c, "CCC");
9 free(c);
10 free(b);
(gdb) b 9
Breakpoint 1 at 0x804843a: file 1.c, line 9.
(gdb) r
Starting program:
/home/piotr/kieszen/in/warsztaty_linux/heap_overflow/robo/1/1
Breakpoint 1, main () at 1.c:9
9 free(c);
Ok, memory should be allocated and filled... Let's examine it:
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x00414141 0x00000000
0x80496e8: 0x00000000 0x00000011 0x00424242 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00434343 0x00000000
Seems that 0x11 is an information about chunk of memory... Bit "1" is
set, because previous chunk is in use. Let's see what happen when it's
freed.

I skip three lines in debugger...
(gdb) n
10 free(b);
(gdb) n
11 free(a);
(gdb) n
12 }

Now let's see at the same location in memory after it's freed.
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x080496e8 0x00000000
0x80496e8: 0x00000000 0x00000011 0x080496f8 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00000000 0x00000000
Ey, what's up?! Bit "1" is still set, even though chunks have been
freed?!

Do you know how is it? I even read sources of malloc.c and tried to look
at malloc.c under debugger, but it seems that line that should set that bit
to "0" is just skipped... Maybe some of you have more experience with
it?

--
zerro - ro**@[127.0.0.1]
Galeria tekstów - czytaj i komentuj cudze, pokaż innym swoje.
http://www.rozrywka.jawsieci.pl/galeria_tekstow/
Nov 14 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
ze***@software.com.pl scribbled the following
on comp.lang.c:
Hello, I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes: I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
} Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb And run it under degugger:


After this, you're off-topic here. This newsgroup is about the C
language, not specific implementations. How malloc() and free() are
implemented at the machine code level is not specified by the ISO C
standard.
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Parthenogenetic procreation in humans will result in the founding of a new
religion."
- John Nordberg
Nov 14 '05 #2

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<c6**********@oravannahka.helsinki.fi>...
ze***@software.com.pl scribbled the following
on comp.lang.c:
Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}

Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb

And run it under degugger:


After this, you're off-topic here. This newsgroup is about the C
language, not specific implementations. How malloc() and free() are
implemented at the machine code level is not specified by the ISO C
standard.


Well. I dont know anything like how to debug before I read this. Can
anyone tell me how tounderstand from the debugger file. I cannot
understand anything from that file "1".
If you could explain that would be great.
ZAPPLE
Nov 14 '05 #3

P: n/a
ZAPPLE <za****@go4.it> scribbled the following:
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<c6**********@oravannahka.helsinki.fi>...
After this, you're off-topic here. This newsgroup is about the C
language, not specific implementations. How malloc() and free() are
implemented at the machine code level is not specified by the ISO C
standard.
Well. I dont know anything like how to debug before I read this. Can
anyone tell me how tounderstand from the debugger file. I cannot
understand anything from that file "1".
If you could explain that would be great.
ZAPPLE


If you read my previous reply, you'll find that I said that specific
implementations are off-topic here. The fact that you need help in
reading debugging output doesn't change that fact.
I suggest asking in comp.unix.programmer or gnu.gcc.help.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'I' is the most beautiful word in the world."
- John Nordberg
Nov 14 '05 #4

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<c6**********@oravannahka.helsinki.fi>...
ze***@software.com.pl scribbled the following
on comp.lang.c:
Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}

Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb

And run it under degugger:


After this, you're off-topic here. This newsgroup is about the C
language, not specific implementations. How malloc() and free() are
implemented at the machine code level is not specified by the ISO C
standard.


Hello,
My computers output is not the same as the one you have printed. One
more thing I cannot really understand, which "1" bit are you speaking
about. I dont have any "1" bit in my debugging output.
I have solaris running and gdb version 5.
ZAPPLE
Nov 14 '05 #5

P: n/a
za****@go4.it scribbled the following:
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<c6**********@oravannahka.helsinki.fi>...
After this, you're off-topic here. This newsgroup is about the C
language, not specific implementations. How malloc() and free() are
implemented at the machine code level is not specified by the ISO C
standard.
Hello,
My computers output is not the same as the one you have printed. One
more thing I cannot really understand, which "1" bit are you speaking
about. I dont have any "1" bit in my debugging output.
I have solaris running and gdb version 5.
ZAPPLE


What part of "specific implementations are off-topic here" didn't you
understand?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Keep shooting, sooner or later you're bound to hit something."
- Misfire
Nov 14 '05 #6

P: n/a
ze***@software.com.pl wrote in message news:<sl******************@piotr.software.com.pl>. ..
Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}

Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb

And run it under degugger:
[piotr::18:49:31]$ gdb 1
GNU gdb 6.0-debian
(...)
(gdb) l
(...)
7 strcpy(b, "BBB");
8 strcpy(c, "CCC");
9 free(c);
10 free(b);
(gdb) b 9
Breakpoint 1 at 0x804843a: file 1.c, line 9.
(gdb) r
Starting program:
/home/piotr/kieszen/in/warsztaty_linux/heap_overflow/robo/1/1
Breakpoint 1, main () at 1.c:9
9 free(c);
Ok, memory should be allocated and filled... Let's examine it:
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x00414141 0x00000000
0x80496e8: 0x00000000 0x00000011 0x00424242 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00434343 0x00000000
Seems that 0x11 is an information about chunk of memory... Bit "1" is
set, because previous chunk is in use. Let's see what happen when it's
freed.

I skip three lines in debugger...
(gdb) n
10 free(b);
(gdb) n
11 free(a);
(gdb) n
12 }

Now let's see at the same location in memory after it's freed.
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x080496e8 0x00000000
0x80496e8: 0x00000000 0x00000011 0x080496f8 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00000000 0x00000000
Ey, what's up?! Bit "1" is still set, even though chunks have been
freed?!

Do you know how is it? I even read sources of malloc.c and tried to look
at malloc.c under debugger, but it seems that line that should set that bit
to "0" is just skipped... Maybe some of you have more experience with
it?

If you want to understand how it works then look at the code in glibc,
it is open for all to read.
Nov 14 '05 #7

P: n/a
In article <news:11**************************@posting.google. com>
<za****@go4.it> writes:
My computers output is not the same as the one [ze***@software.com.pl

showed in <news:$6****@oravannahka.helsinki.fi>].

Indeed, this is the point: the details on how to run a debugger,
and what might be happening "under the hood" on any particular
C implementation, are allowed to -- and do -- change from one
implementation to the next. The comp.lang.c group is already busy
enough with postings about things that do NOT change from one
implementation to the next, so if you want implementation-specific
details, you need an implementation-specific newsgroup.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #8

P: n/a
ze***@software.com.pl writes:
Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}


Questions about gdb or about the internal workings of a particular
implementation are, as others have pointed out, off-topic here.
Questions about the standard malloc and free functions are topical,
but in this case I think your questions can be answered by reading the
FAQ.

By calling free(), you're telling the system that you're finished with
the memory that was previously allocated by malloc(). It's invalid to
attempt to examine that memory after calling free(). If you were
still interested in examining it, you shouldn't have told the system
that you were finished with it.

The C FAQ is at <http://www.eskimo.com/~scs/C-faq/faq.html>. See
question 7.20 and 7.21. Once you've done that, you should read all of
section 7, and then the entire FAQ. If you still have questions after
that, feel free to post them -- but remember that we can't help you
with gdb.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #9

P: n/a
AFAK malloc usually manages a list. When you do a free the freed bloc is
added to the free blocks lists. Allocated memory is not affected.

Then there are many algorithms, if you are interested in the most used
on linux you should have a look at glibc; but many project make their
own allocation library ( or use a special version ) which I think calls
directly sbrk

Rob Thorpe wrote:
ze***@software.com.pl wrote in message news:<sl******************@piotr.software.com.pl>. ..
Hello,

I try to understand heap overflows (under Linux), but can not understand
one
thing with freeing memory allocated with malloc(). Here it comes:

I have a program called 1.c:
main() {
char *a, *b, *c, *d, *e;
a = malloc(8);
b = malloc(8);
c = malloc(8);
strcpy(a, "AAA");
strcpy(b, "BBB");
strcpy(c, "CCC");
free(c);
free(b);
free(a);
}

Well, quite simple. Now I compile it:
[piotr::18:46:23]$ gcc 1.c -o 1 -ggdb

And run it under degugger:
[piotr::18:49:31]$ gdb 1
GNU gdb 6.0-debian
(...)
(gdb) l
(...)
7 strcpy(b, "BBB");
8 strcpy(c, "CCC");
9 free(c);
10 free(b);
(gdb) b 9
Breakpoint 1 at 0x804843a: file 1.c, line 9.
(gdb) r
Starting program:
/home/piotr/kieszen/in/warsztaty_linux/heap_overflow/robo/1/1
Breakpoint 1, main () at 1.c:9
9 free(c);
Ok, memory should be allocated and filled... Let's examine it:
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x00414141 0x00000000
0x80496e8: 0x00000000 0x00000011 0x00424242 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00434343 0x00000000
Seems that 0x11 is an information about chunk of memory... Bit "1" is
set, because previous chunk is in use. Let's see what happen when it's
freed.

I skip three lines in debugger...
(gdb) n
10 free(b);
(gdb) n
11 free(a);
(gdb) n
12 }

Now let's see at the same location in memory after it's freed.
(gdb) x/12 a-8
0x80496d8: 0x00000000 0x00000011 0x080496e8 0x00000000
0x80496e8: 0x00000000 0x00000011 0x080496f8 0x00000000
0x80496f8: 0x00000000 0x00000011 0x00000000 0x00000000
Ey, what's up?! Bit "1" is still set, even though chunks have been
freed?!

Do you know how is it? I even read sources of malloc.c and tried to look
at malloc.c under debugger, but it seems that line that should set that bit
to "0" is just skipped... Maybe some of you have more experience with
it?


If you want to understand how it works then look at the code in glibc,
it is open for all to read.


Nov 14 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.