Connecting Tech Pros Worldwide Help | Site Map

malloc segmentation fault

Bin Lu
Guest
 
Posts: n/a
#1: Nov 13 '05

I keep getting this malloc problem when my program tries to allocate
memory for some pointer. The statement is like:

rsv_cache = (rsvcache *) malloc (sizeof(rsvcache));

It goes through the function with this statement several times and seems
that it has successfully allocated the memory. and then at some
iteration, it just gets this segmentation fault.

The gdb gives the following message:

Program received signal SIGSEGV, Segmentation fault.
0x4022e221 in chunk_alloc (ar_ptr=0x402e2620, nb=48) at malloc.c:2878
2878 malloc.c: No such file or directory.
in malloc.c

And when I try to run the program with some other data, it gets exactly
the same problem but at another malloc statement in my code.

Any idea what this is about and how to solve it?? I'd appreciate it very
much if you can give me a hint!!

Bin Lu
Dave Vandervies
Guest
 
Posts: n/a
#2: Nov 13 '05

re: malloc segmentation fault


In article <Pine.GSO.4.58.0310031546010.12674@unix.cs.tamu.ed u>,
Bin Lu <b0l4549@cs.tamu.edu> wrote:[color=blue]
>
>I keep getting this malloc problem when my program tries to allocate
>memory for some pointer. The statement is like:
>
>rsv_cache = (rsvcache *) malloc (sizeof(rsvcache));[/color]

Better (but not, if I'm guessing correctly, related to your problem)
would be to call malloc like this:
rsv_cache = malloc(sizeof *rsv_cache);
Casting the return value doesn't gain you anything and can hide failure to
#include <stdlib.h>, and giving sizeof an object of the right type (based
on the pointer you're assigning its return value to) is widely considered
to be clearer and more maintainable than directly giving it a type.
[color=blue]
>
>It goes through the function with this statement several times and seems
>that it has successfully allocated the memory. and then at some
>iteration, it just gets this segmentation fault.
>
>The gdb gives the following message:
>
>Program received signal SIGSEGV, Segmentation fault.
>0x4022e221 in chunk_alloc (ar_ptr=0x402e2620, nb=48) at malloc.c:2878
>2878 malloc.c: No such file or directory.
> in malloc.c
>
>And when I try to run the program with some other data, it gets exactly
>the same problem but at another malloc statement in my code.[/color]

Most likely, you're scribbling over memory that malloc and friends use
for their internal bookkeeping or doing something silly like trying to
free the same pointer twice.

Go through your code carefully and make sure that:
-Everything that fgets mallocd fgets freed exactly once
-Every time you dereference a pointer into mallocd memory, it's inside
the size bounds passed to malloc originally
-You don't try to dereference[1] any pointers into mallocd memory you've
already given back to free

My guess would be that in the process of doing so you'll find (and
hopefully fix) a few bugs and, as a result of that, the problem is likely
to go away.


dave

[1] Or use at all, though on the system you appear to be using it's not
likely to cause any problems to just pass around the value of a
dead pointer
--
Dave Vandervies dj3vande@csclub.uwaterloo.ca
The n869 draft does not define the language, but this non-definition is more
authoritative (though less readable) than K&R's non-definition of the language.
--Richard Heathfield in comp.lang.c
David Rubin
Guest
 
Posts: n/a
#3: Nov 13 '05

re: malloc segmentation fault


Bin Lu wrote:[color=blue]
>
> I keep getting this malloc problem when my program tries to allocate
> memory for some pointer. The statement is like:
>
> rsv_cache = (rsvcache *) malloc (sizeof(rsvcache));
>
> It goes through the function with this statement several times and seems
> that it has successfully allocated the memory. and then at some
> iteration, it just gets this segmentation fault.[/color]

Either you are allocating more memory than the machine can spare, or you
are leaking memory. Based on your snippet, you don't seem to be checking
whether malloc fails. You should.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown
Jens.Toerring@physik.fu-berlin.de
Guest
 
Posts: n/a
#4: Nov 13 '05

re: malloc segmentation fault


Bin Lu <b0l4549@cs.tamu.edu> wrote:
[color=blue]
> I keep getting this malloc problem when my program tries to allocate
> memory for some pointer. The statement is like:[/color]
[color=blue]
> rsv_cache = (rsvcache *) malloc (sizeof(rsvcache));[/color]

The cast is unnecessary and even contra-productive because it keeps
the compiler from warning you if you forgot to include <stdlib.h>
[color=blue]
> It goes through the function with this statement several times and seems
> that it has successfully allocated the memory. and then at some
> iteration, it just gets this segmentation fault.[/color]
[color=blue]
> The gdb gives the following message:[/color]
[color=blue]
> Program received signal SIGSEGV, Segmentation fault.
> 0x4022e221 in chunk_alloc (ar_ptr=0x402e2620, nb=48) at malloc.c:2878
> 2878 malloc.c: No such file or directory.
> in malloc.c[/color]
[color=blue]
> And when I try to run the program with some other data, it gets exactly
> the same problem but at another malloc statement in my code.[/color]
[color=blue]
> Any idea what this is about and how to solve it?? I'd appreciate it very
> much if you can give me a hint!![/color]

That's a typical symptom: you got memory corruption somewhere in your
program (e.g. by writing past the end of an array or beyound the
boundaries of memory you allocated or you're using an uninitialized
pointer) and sometime later in some completely innocent looking place
it suddenly bites back with a segfault. Stop looking for the error in
the call of malloc() and check everywhere else for problems. Better,
get a memory debugger and let it help you figure out where exactly the
s..t hit the fan. If the program isn't too long you can also post it
here.
Regards, Jens
--
_ _____ _____
| ||_ _||_ _| Jens.Toerring@physik.fu-berlin.de
_ | | | | | |
| |_| | | | | | http://www.physik.fu-berlin.de/~toerring
\___/ens|_|homs|_|oerring
Eric Sosman
Guest
 
Posts: n/a
#5: Nov 13 '05

re: malloc segmentation fault


Bin Lu wrote:[color=blue]
>
> I keep getting this malloc problem when my program tries to allocate
> memory for some pointer. [...][/color]

This is Question 7.19 in the comp.lang.c Frequently
Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

--
Eric.Sosman@sun.com
Erik de Castro Lopo
Guest
 
Posts: n/a
#6: Nov 13 '05

re: malloc segmentation fault


Bin Lu wrote:[color=blue]
>
> I keep getting this malloc problem when my program tries to allocate
> memory for some pointer. The statement is like:
>
> rsv_cache = (rsvcache *) malloc (sizeof(rsvcache));[/color]

As others have said, don't cast the return of malloc.
[color=blue]
> It goes through the function with this statement several times and seems
> that it has successfully allocated the memory. and then at some
> iteration, it just gets this segmentation fault.[/color]

This is almost certain, your program corrupting heap memory. There
are probably 100 ways to do this, including writing past the end of
a buffer, incorrect array indexing and so on.

I notice that you are posting this using Pine and using gdb
for debugging. This means that there is also some chance that
you are running Linux. If that is the case, search
http://freshmeat.net/ for a program called valgrind (only
works on i386 Linux unfortunately) which is really good at
finding bugs like this.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"One of the great things about books is sometimes there are
some fantastic pictures" - George W. Bush
Default User
Guest
 
Posts: n/a
#7: Nov 13 '05

re: malloc segmentation fault


Bin Lu wrote:
[color=blue]
> It goes through the function with this statement several times and seems
> that it has successfully allocated the memory. and then at some
> iteration, it just gets this segmentation fault.[/color]

See the FAQ question titled "7.19 My program is crashing, apparently
somewhere down inside malloc."

http://www.eskimo.com/~scs/C-faq/q7.19.html



Always check the FAQ list first.




Brian Rodenborn
Bin Lu
Guest
 
Posts: n/a
#8: Nov 13 '05

re: malloc segmentation fault



Thanks for giving me so many hints! I checked every possible problem as
you guys have suggested and fixed a few bugs. But it still gets segfault,
which is over my head...

I installed valgrind. The error message I got is as follows:

-----------------------------------------
Conditional jump or move depends on uninitialised value(s)
==1200== at 0x8114324: INSIGNIA::local_bw_monitor(Packet*)
(insignia.cc:781)
==1200== by 0x8112E7B: INSIGNIA::tap(Packet const*) (insignia.cc:242)
==1200== by 0x80FAA31: Mac802_11::recv_timer() (in
/usr/ns-allinone-2.26/ns-2.26/ns)
==1200== by 0x80F89CE: Mac802_11::recvHandler() (in
/usr/ns-allinone-2.26/ns-2.26/ns)
==1200==
==1200== Invalid read of size 4
==1200== at 0x806AA44: PacketQueue::head() (in
/usr/ns-allinone-2.26/ns-2.26/ns)
==1200== by 0x8138CA3: AODV::rt_ll_failed(Packet*) (in
/usr/ns-allinone-2.26/ns-2.26/ns)
==1200== by 0x8138AED: aodv_rt_failed_callback(Packet*, void*) (in
/usr/ns-allinone-2.26/ns-2.26/ns)
==1200== by 0x80FA17D: Mac802_11::RetransmitRTS() (in
/usr/ns-allinone-2.26/ns-2.26/ns)
==1200== Address 0x10 is not stack'd, malloc'd or free'd
Segmentation fault
----------------------------

I guess it is the last one that causes the segfault. I don't why it gets
to read from some wrong address? After I run this program, some of
applications of my Redhat (9.0) is not working right.
Could you give me a hint what can cause this kind of error? I can't figure
out how to fix this.

Thanks a million!

Bin Lu

On Fri, 3 Oct 2003, Erik de Castro Lopo wrote:
[color=blue]
> Bin Lu wrote:[color=green]
> >
> > I keep getting this malloc problem when my program tries to allocate
> > memory for some pointer. The statement is like:
> >
> > rsv_cache = (rsvcache *) malloc (sizeof(rsvcache));[/color]
>
> As others have said, don't cast the return of malloc.
>[color=green]
> > It goes through the function with this statement several times and seems
> > that it has successfully allocated the memory. and then at some
> > iteration, it just gets this segmentation fault.[/color]
>
> This is almost certain, your program corrupting heap memory. There
> are probably 100 ways to do this, including writing past the end of
> a buffer, incorrect array indexing and so on.
>
> I notice that you are posting this using Pine and using gdb
> for debugging. This means that there is also some chance that
> you are running Linux. If that is the case, search
> http://freshmeat.net/ for a program called valgrind (only
> works on i386 Linux unfortunately) which is really good at
> finding bugs like this.
>
> Erik
> --
> +-----------------------------------------------------------+
> Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid)
> +-----------------------------------------------------------+
> "One of the great things about books is sometimes there are
> some fantastic pictures" - George W. Bush
>[/color]
Bin Lu
Guest
 
Posts: n/a
#9: Nov 13 '05

re: malloc segmentation fault



Still this memory problem. I added the gdb backtrace to the end of this
message, so that it gives more information. The code is too huge to post
here. :(

Any hint will be highly appreciated!! Thanks so very very much!!!
[color=blue]
>
> I installed valgrind. The error message I got is as follows:
>
> -----------------------------------------
> Conditional jump or move depends on uninitialised value(s)
> ==1200== at 0x8114324: INSIGNIA::local_bw_monitor(Packet*)
> (insignia.cc:781)
> ==1200== by 0x8112E7B: INSIGNIA::tap(Packet const*) (insignia.cc:242)
> ==1200== by 0x80FAA31: Mac802_11::recv_timer() (in
> /usr/ns-allinone-2.26/ns-2.26/ns)
> ==1200== by 0x80F89CE: Mac802_11::recvHandler() (in
> /usr/ns-allinone-2.26/ns-2.26/ns)
> ==1200==
> ==1200== Invalid read of size 4
> ==1200== at 0x806AA44: PacketQueue::head() (in
> /usr/ns-allinone-2.26/ns-2.26/ns)
> ==1200== by 0x8138CA3: AODV::rt_ll_failed(Packet*) (in
> /usr/ns-allinone-2.26/ns-2.26/ns)
> ==1200== by 0x8138AED: aodv_rt_failed_callback(Packet*, void*) (in
> /usr/ns-allinone-2.26/ns-2.26/ns)
> ==1200== by 0x80FA17D: Mac802_11::RetransmitRTS() (in
> /usr/ns-allinone-2.26/ns-2.26/ns)
> ==1200== Address 0x10 is not stack'd, malloc'd or free'd
> Segmentation fault
> ----------------------------
>
> I guess it is the last one that causes the segfault. I don't why it gets
> to read from some wrong address? After I run this program, some of
> applications of my Redhat (9.0) is not working right.[/color]

The gdb debugger shows:
-------------------------------------
Received signal SIGSEGV, Segmentation fault.
0x0806aa44 in PacketQueue::head() ()
(gdb) bt
#0 0x0806aa44 in PacketQueue::head() ()
#1 0x08115eae in PriQueue::filter(int) ()
#2 0x08138cbc in AODV::rt_ll_failed(Packet*) ()
#3 0x08138b06 in aodv_rt_failed_callback(Packet*,
void*) ()
#4 0x080fa17e in Mac802_11::RetransmitRTS() ()
#5 0x080f8a54 in Mac802_11::send_timer() ()
#6 0x080f89e5 in Mac802_11::sendHandler() ()
#7 0x081194de in TxTimer::handle(Event*) ()
#8 0x080545bc in Scheduler::dispatch(Event*, double)
()
#9 0x0805451d in Scheduler::run() ()
#10 0x080546b9 in Scheduler::command(int, char const*
const*) ()
#11 0x081f4ca6 in TclClass::dispatch_cmd(void*,
Tcl_Interp*, int, char**) ()
#12 0x081f879e in OTclDispatch (cd=0x8445958,
in=0x83b5b40, argc=3,
argv=0xbfffc410) at otcl.c:420
#13 0x081fcfa0 in TclInvokeStringCommand ()
#14 0x0821703b in TclExecuteByteCode ()
#15 0x081fd94b in Tcl_EvalObjEx ()
#16 0x08217227 in TclExecuteByteCode ()
#17 0x081fd94b in Tcl_EvalObjEx ()
#18 0x082388db in TclObjInterpProc ()
#19 0x0823848a in TclProcInterpProc ()
#20 0x081f893a in OTclDispatch (cd=0x8445958,
in=0x83b5b40, argc=2,
argv=0xbfffcc60) at otcl.c:463
---Type <return> to continue, or q <return> to quit---
#21 0x081fcfa0 in TclInvokeStringCommand ()
#22 0x0821703b in TclExecuteByteCode ()
#23 0x081fd94b in Tcl_EvalObjEx ()
#24 0x082388db in TclObjInterpProc ()
#25 0x0823848a in TclProcInterpProc ()
#26 0x081f879e in OTclDispatch (cd=0x8556ff0,
in=0x83b5b40, argc=2,
argv=0xbfffd330) at otcl.c:420
#27 0x081fcfa0 in TclInvokeStringCommand ()
#28 0x08231fd9 in EvalObjv ()
#29 0x08232666 in Tcl_EvalEx ()
#30 0x08229d1a in Tcl_EvalFile ()
#31 0x0822c7db in Tcl_Main ()
#32 0x0804e6ff in main ()
#33 0x42015574 in __libc_start_main () from
/lib/tls/libc.so.6
(gdb)
-----------------------------

Does this mean that the segfault happens exactly in function
PacketQueue::head()?
[color=blue]
>
> Bin Lu
>[/color]


Mark McIntyre
Guest
 
Posts: n/a
#10: Nov 13 '05

re: malloc segmentation fault


On Thu, 23 Oct 2003 15:17:21 -0500, in comp.lang.c , Bin Lu
<b0l4549@cs.tamu.edu> wrote:
[color=blue]
>
>Still this memory problem. I added the gdb backtrace to the end of this
>message, so that it gives more information. The code is too huge to post
>here. :(
>
>Any hint will be highly appreciated!! Thanks so very very much!!![/color]

first hint: this looks like C++, thats down the hall in CLC++, you're
in CLC here.
However they're not going to be able to help much either. You need
work on reducing your code fragment to the smallest compilable example
that still exhibits the problem. I know this doesn't sound much fun
but if you can't post some code, its almost inconcievable that anyone
can find your error.

snippage
[color=blue]
>Does this mean that the segfault happens exactly in function
>PacketQueue::head()?[/color]

more likely it means that the segfault happens there, because you
corrupted your memory somewhere else. Typically not allocating enough
memory, forgetting to check a pointer for NULL, overrunning a buffer,
or writing to readonly memory.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Closed Thread