Malloc bug?

Malloc bug?

[Nathan Ingersoll]

I've been working on a GTK program for a while now, and I've been
experiencing segfaults within malloc. I was under the impression that
malloc should always return successfully (at least that's what the man
page says). Any ideas what may be causing this? I don't know if this has
anything to do with it, but the kernel I was using generated lots of
vm_do_try_free_pages failed error logs but not necessarily during program
execution.

---------------------------------------------------------------------------
|   Nathan Ingersoll             |   Computer Science/Mathematics         |
|   mailto: ningerso@d.umn.edu   |   University of Minnesota-Duluth       |
|   http://umn.edu/~ningerso     |   http://www.d.umn.edu                 |
---------------------------------------------------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[Paul Schinder]

At 3:40 PM -0500 7/18/00, Nathan Ingersoll wrote:
>I've been working on a GTK program for a while now, and I've been
>experiencing segfaults within malloc. I was under the impression that
>malloc should always return successfully (at least that's what the man
>page says).

No, it shouldn't.  If there's no memory left, it will return NULL.
Software should be checking for this.

>Any ideas what may be causing this? I don't know if this has
>anything to do with it, but the kernel I was using generated lots of
>vm_do_try_free_pages failed error logs but not necessarily during program
>execution.
>
>---------------------------------------------------------------------------
>|   Nathan Ingersoll             |   Computer Science/Mathematics         |
>|   mailto: ningerso@d.umn.edu   |   University of Minnesota-Duluth       |
>|   http://umn.edu/~ningerso     |   http://www.d.umn.edu                 |
>---------------------------------------------------------------------------
>
>

--
--
Paul Schinder
schinder@pobox.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[Nathan Ingersoll]

On Tue, 18 Jul 2000, Paul Schinder wrote:

> At 3:40 PM -0500 7/18/00, Nathan Ingersoll wrote:
> >I've been working on a GTK program for a while now, and I've been
> >experiencing segfaults within malloc. I was under the impression that
> >malloc should always return successfully (at least that's what the man
> >page says).
>
> No, it shouldn't.  If there's no memory left, it will return NULL.
> Software should be checking for this.

Right, but it's not returning at all. It's segfaulting inside the malloc
function before it returns anything.

---------------------------------------------------------------------------
|   Nathan Ingersoll             |   Computer Science/Mathematics         |
|   mailto: ningerso@d.umn.edu   |   University of Minnesota-Duluth       |
|   http://umn.edu/~ningerso     |   http://www.d.umn.edu                 |
---------------------------------------------------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[David Edelsohn]

>>>>> Nathan Ingersoll writes:

Nathan> On Tue, 18 Jul 2000, Paul Schinder wrote:

>> At 3:40 PM -0500 7/18/00, Nathan Ingersoll wrote:
>> >I've been working on a GTK program for a while now, and I've been
>> >experiencing segfaults within malloc. I was under the impression that
>> >malloc should always return successfully (at least that's what the man
>> >page says).

Nathan> Right, but it's not returning at all. It's segfaulting inside the malloc
Nathan> function before it returns anything.

	Sounds more like something is overwriting one of malloc's internal
data areas or possibly hitting some weird ulimit symptom.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[David A. Gatwood]

On Tue, 18 Jul 2000, Nathan Ingersoll wrote:

> I've been working on a GTK program for a while now, and I've been
> experiencing segfaults within malloc. I was under the impression that
> malloc should always return successfully (at least that's what the man
> page says).


Sounds like the man page is wrong.  :-)  Malloc returns NULL if:

1.	the machine's virtual memory is exhausted
2.	the process's maximum virtual memory (set by ulimit) is exhausted
3.	the process's virtual memory has been hosed.

There may be other cases, but I can't think of them, if there are.  The
first two are fairly trivial, and shouldn't happen unless you're
allocating in an infinite loop or something.

There are four ways to get #3 that I can think of, probably more, but
these are the first ones that come to mind:

a.	call free() on an unitialized pointer (containing random data).
b.	call free() twice on the same memory region.
c.	call free() on the middle of a malloc'ed region.
d.	call free() on a variable allocated by something other than
	malloc, e.g. a stack variable (in a function or a function call),
	a static variable (or any global variable), or a region allocated
	by the C++ new function.

Anyway, you should always check the return value of malloc.  :-)


> Any ideas what may be causing this? I don't know if this has
> anything to do with it, but the kernel I was using generated lots of
> vm_do_try_free_pages failed error logs but not necessarily during program
> execution.

No idea about that.  The earlier points are machine-independent.  The
above looks like it's specific to the PPC monolithic kernel and/or GTK,
neither of which I do much with.


David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[David A. Gatwood]

On Tue, 18 Jul 2000, Nathan Ingersoll wrote:

>
> On Tue, 18 Jul 2000, Paul Schinder wrote:
>
> > At 3:40 PM -0500 7/18/00, Nathan Ingersoll wrote:
> > >I've been working on a GTK program for a while now, and I've been
> > >experiencing segfaults within malloc. I was under the impression that
> > >malloc should always return successfully (at least that's what the man
> > >page says).
> >
> > No, it shouldn't.  If there's no memory left, it will return NULL.
> > Software should be checking for this.
>
> Right, but it's not returning at all. It's segfaulting inside the malloc
> function before it returns anything.

See my comments in the message I sent a few minutes ago.  Any of the #3
problems with free() can cause this.


Later,
David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[Sean Chitwood]

I've seen this before while trying to debug mozilla. Once I loaded the glibc symbols it stopped breaking, so I'd set a breakpt @ main() then load the symbols.

	Sean

On Tue, 18 Jul 2000, David Edelsohn wrote:

>
> >>>>> Nathan Ingersoll writes:
>
> Nathan> On Tue, 18 Jul 2000, Paul Schinder wrote:
>
> >> At 3:40 PM -0500 7/18/00, Nathan Ingersoll wrote:
> >> >I've been working on a GTK program for a while now, and I've been
> >> >experiencing segfaults within malloc. I was under the impression that
> >> >malloc should always return successfully (at least that's what the man
> >> >page says).
>
> Nathan> Right, but it's not returning at all. It's segfaulting inside the malloc
> Nathan> function before it returns anything.
>
> 	Sounds more like something is overwriting one of malloc's internal
> data areas or possibly hitting some weird ulimit symptom.
>
> David
>
>
>

	Sean aka Darkmane
+------------------------------
+ On October 16, 1999 A.D.
+ Sean Chitwood proudly proclaimed
+ his love for Melissa Webb
+ and made her his lifemate
+------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[Hollis Blanchard]

Nathan Ingersoll wrote:
>
> I've been working on a GTK program for a while now, and I've been
> experiencing segfaults within malloc.

In my experience this is almost always caused by overwriting array
bounds somewhere before that. (Learning how malloc works helps you
understand why.) Go check all your memory accesses. Electric Fence might
help.

-Hollis

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[William Blew]

On Tue, 18 Jul 2000, David A. Gatwood wrote:

Anybody know here man page patches are submitted? After all, if the
man page is incorrect, an easy fix is to update it :).

BTW: David, thanks for the info.

> On Tue, 18 Jul 2000, Nathan Ingersoll wrote:
>
> > I've been working on a GTK program for a while now, and I've been
> > experiencing segfaults within malloc. I was under the impression that
> > malloc should always return successfully (at least that's what the man
> > page says).
>
>
> Sounds like the man page is wrong.  :-)  Malloc returns NULL if:
>
> 1.	the machine's virtual memory is exhausted
> 2.	the process's maximum virtual memory (set by ulimit) is exhausted
> 3.	the process's virtual memory has been hosed.
>
> There may be other cases, but I can't think of them, if there are.  The
> first two are fairly trivial, and shouldn't happen unless you're
> allocating in an infinite loop or something.
>
> There are four ways to get #3 that I can think of, probably more, but
> these are the first ones that come to mind:
>
> a.	call free() on an unitialized pointer (containing random data).
> b.	call free() twice on the same memory region.
> c.	call free() on the middle of a malloc'ed region.
> d.	call free() on a variable allocated by something other than
> 	malloc, e.g. a stack variable (in a function or a function call),
> 	a static variable (or any global variable), or a region allocated
> 	by the C++ new function.
>
> Anyway, you should always check the return value of malloc.  :-)
>
>
> > Any ideas what may be causing this? I don't know if this has
> > anything to do with it, but the kernel I was using generated lots of
> > vm_do_try_free_pages failed error logs but not necessarily during program
> > execution.
>
> No idea about that.  The earlier points are machine-independent.  The
> above looks like it's specific to the PPC monolithic kernel and/or GTK,
> neither of which I do much with.
>
>
> David
>
> ---------------------------------------------------------------------
> A brief Haiku:
>
> Microsoft is bad.
> It seems secure at first glance.
> Then you read your mail.
>
>
>

--
William Blew, wblew@home.com
Gamer by Choice, Geek by Birth


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[Paul Schinder]

At 9:30 AM -0700 7/19/00, William Blew wrote:
>
>Anybody know here man page patches are submitted? After all, if the
>man page is incorrect, an easy fix is to update it :).
>

The man page isn't incorrect, at least not the one I have (YDL CS 1.2):


RETURN VALUES
        For calloc() and malloc(), the value returned is a pointer
        to the allocated memory, which is suitably aligned for any
        kind of variable, or NULL if the request fails.

        free() returns no value.

        realloc() returns a pointer to the newly allocated memory,
        which is suitably aligned for any kind of variable and may
        be different from ptr, or NULL if the request fails or  if
        size  was  equal  to  0.   If realloc() fails the original
        block is left untouched - it is not freed or moved.

and

NOTES
        The Unix98 standard requires malloc(), calloc(), and real-
        loc()  to  set errno to ENOMEM upon failure. Glibc assumes
        that this is done (and the glibc versions  of  these  rou-
        tines do this); if you use a private malloc implementation
        that does not set errno, then certain library routines may
        fail without having a reason in errno.

>

--
--
Paul Schinder
schinder@pobox.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[Nathan Ingersoll]

According to what others have said, my program is probably overwriting a
buffer, or incorrectly freeing some variable, thus corrupting mallocs data
structures and causing a crash. So malloc works the way the man page
states, just not when its been corrupted.

---------------------------------------------------------------------------
|   Nathan Ingersoll             |   Computer Science/Mathematics         |
|   mailto: ningerso@d.umn.edu   |   University of Minnesota-Duluth       |
|   http://umn.edu/~ningerso     |   http://www.d.umn.edu                 |
---------------------------------------------------------------------------

On Wed, 19 Jul 2000, William Blew wrote:

> On Tue, 18 Jul 2000, David A. Gatwood wrote:
>
> Anybody know here man page patches are submitted? After all, if the
> man page is incorrect, an easy fix is to update it :).
>
> BTW: David, thanks for the info.
>
> > On Tue, 18 Jul 2000, Nathan Ingersoll wrote:
> >
> > > I've been working on a GTK program for a while now, and I've been
> > > experiencing segfaults within malloc. I was under the impression that
> > > malloc should always return successfully (at least that's what the man
> > > page says).
> >
> >
> > Sounds like the man page is wrong.  :-)  Malloc returns NULL if:
> >
> > 1.	the machine's virtual memory is exhausted
> > 2.	the process's maximum virtual memory (set by ulimit) is exhausted
> > 3.	the process's virtual memory has been hosed.
> >
> > There may be other cases, but I can't think of them, if there are.  The
> > first two are fairly trivial, and shouldn't happen unless you're
> > allocating in an infinite loop or something.
> >
> > There are four ways to get #3 that I can think of, probably more, but
> > these are the first ones that come to mind:
> >
> > a.	call free() on an unitialized pointer (containing random data).
> > b.	call free() twice on the same memory region.
> > c.	call free() on the middle of a malloc'ed region.
> > d.	call free() on a variable allocated by something other than
> > 	malloc, e.g. a stack variable (in a function or a function call),
> > 	a static variable (or any global variable), or a region allocated
> > 	by the C++ new function.
> >
> > Anyway, you should always check the return value of malloc.  :-)
> >
> >
> > > Any ideas what may be causing this? I don't know if this has
> > > anything to do with it, but the kernel I was using generated lots of
> > > vm_do_try_free_pages failed error logs but not necessarily during program
> > > execution.
> >
> > No idea about that.  The earlier points are machine-independent.  The
> > above looks like it's specific to the PPC monolithic kernel and/or GTK,
> > neither of which I do much with.
> >
> >
> > David
> >
> > ---------------------------------------------------------------------
> > A brief Haiku:
> >
> > Microsoft is bad.
> > It seems secure at first glance.
> > Then you read your mail.
> >
> >
> >
>
> --
> William Blew, wblew@home.com
> Gamer by Choice, Geek by Birth
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[David A. Gatwood]

On Wed, 19 Jul 2000, William Blew wrote:

> On Tue, 18 Jul 2000, David A. Gatwood wrote:
>
> Anybody know here man page patches are submitted? After all, if the
> man page is incorrect, an easy fix is to update it :).
>
> BTW: David, thanks for the info.

No prob.  And Hollis made another good point about running past the bounds
of a memory region.  Same applies for any data structure (arrays, etc.).
Another common problem is to compile against a set of headers for a
library where the library itself doesn't match.  This can cause the size
of objects to change, and you run over the bounds without even knowing it.


David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Malloc bug?

[David A. Gatwood]

On Wed, 19 Jul 2000, Paul Schinder wrote:

>
> At 9:30 AM -0700 7/19/00, William Blew wrote:
> >
> >Anybody know here man page patches are submitted? After all, if the
> >man page is incorrect, an easy fix is to update it :).
> >
>
> The man page isn't incorrect, at least not the one I have (YDL CS 1.2):

I recall reading something about malloc never failing in some malloc man
page, but I don't recall which OS, which version, etc.

I note in the MkLinux man page, which is probably straight from RedHat:

       free()  frees  the  memory  space pointed to by ptr, which
       must have been returned by a previous  call  to  malloc(),
       calloc()  or  realloc().   Otherwise,  or if free(ptr) has
       already been called before,  undefined  behaviour  occurs.
       If ptr is NULL, no operation is performed.

and

       Crashes in malloc(), free() or realloc() are almost always
       related to heap corruption, such as overflowing  an  allo-
       cated chunk or freeing the same pointer twice.

:-)


David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/