Date: Mon, 22 Sep 2008 02:31:57 +0100 From: RW <fbsd06@mlists.homeunix.com> To: freebsd-questions@freebsd.org Subject: Re: Segmentation fault when free Message-ID: <20080922023157.6668b46f@gumby.homeunix.com.> In-Reply-To: <266527.92897.qm@web110502.mail.gq1.yahoo.com> References: <200809210206.52409.fbsd.questions@rachie.is-a-geek.net> <266527.92897.qm@web110502.mail.gq1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Sep 2008 05:57:06 -0700 (PDT)
Nash Nipples <trashy_bumper@yahoo.com> wrote:
> but even if you kill -SEGV `pgrep this` (Segmentation fault (core
> dumped) the memory is getting freed anyway (presumably by the
> glorious kernel). which you can see dynamicly by typing top in the
> console.
The idea that malloc() allocates memory is really a C language
abstraction. What it actually does is allocate a region in the
process's virtual address space. The mapping of physical memory to
virtual address space is handled at a lower-level and doesn't rely on
malloc() or free().
> in other words segmentation fault when free() is not a scary thing
> here. it is a matter of style and the way to find own errors. or
> maybe reading warnings if you compile with the flags -ansi -pedantic
I'm not sure what you are saying here, but the handling of dynamic
memory in C is something that needs to be well thought-out in
advance. Bugs is this area can be very difficult and time-consuming
to track-down.
> oh and by the way:
>
> > char *
> > function(void)
> > {
> > char buffer[100];
> >
> > return buffer;
> > }
>
> that is an easier approach because you get warned on passing an
> address to a local variable
This was an example of how to generate a failure, it's not an approach.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080922023157.6668b46f>