malloc behavior on failure

Discussion in 'C Programming' started by gooch, Feb 28, 2006.

  1. gooch

    gooch Guest

    I originally posted the following code in a group discussing threads
    but after further research I think I have a c question about the code.
    I know there are a couple of non standard c includes here and the POSIX
    stuff is non standard but this is how I stumbled onto this question.

    #include <INTEGRITY.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <pthread.h>
    #include <signal.h>
    #include <time.h>

    timer_t l_timer_2;
    int counter =0;

    //void Test(union sigval sigval)
    void Test (union sigval sigval)
    {
    printf("Count\n");
    counter++;

    return;
    }


    int main()
    {
    struct itimerspec l_timer_spec1;
    struct sigevent l_tevent1;
    int *ptr;
    int status;

    l_tevent1.sigev_notify = SIGEV_THREAD;
    l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    l_tevent1.sigev_notify_function = Test;
    l_tevent1.sigev_notify_attributes = NULL;
    l_tevent1.sigev_signo = SIGRTMIN;
    l_timer_spec1.it_interval.tv_sec = 2;
    l_timer_spec1.it_interval.tv_nsec = 0;
    //set subsequent timer intervals
    l_timer_spec1.it_value.tv_sec = 2;
    l_timer_spec1.it_value.tv_nsec = 0;

    //create timer
    if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    {
    status = 1;
    }

    if (status == 0)
    {
    if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    {
    status = 1;
    }
    }

    ptr = malloc(1000000);

    if (ptr == NULL)
    printf("NULL PTR\n");

    counter++;

    Exit(0);
    }

    Now I know this code snipet is pretty useless but it was the result of
    troubleshooting a problem. When the malloc fails the timer stops
    operating as expected. After some research it appears that when malloc
    fails, returns NULL, due to not enough resources it actually marks all
    the available memory as allocated. Due to this the timer can't start
    the thread when it pops. So my question is what, if anything, does the
    standard have to say about the behavior of malloc in this situation. Is
    this behavior allowed and if so is it common. It seems to me that there
    are many more gracefull ways for this to fail.
    gooch, Feb 28, 2006
    #1
    1. Advertising

  2. gooch

    Jack Klein Guest

    On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote in
    comp.lang.c:

    > I originally posted the following code in a group discussing threads
    > but after further research I think I have a c question about the code.
    > I know there are a couple of non standard c includes here and the POSIX
    > stuff is non standard but this is how I stumbled onto this question.
    >
    > #include <INTEGRITY.h>
    > #include <stdlib.h>
    > #include <stdio.h>
    > #include <pthread.h>
    > #include <signal.h>
    > #include <time.h>
    >
    > timer_t l_timer_2;
    > int counter =0;
    >
    > //void Test(union sigval sigval)
    > void Test (union sigval sigval)
    > {
    > printf("Count\n");
    > counter++;
    >
    > return;
    > }
    >
    >
    > int main()
    > {
    > struct itimerspec l_timer_spec1;
    > struct sigevent l_tevent1;
    > int *ptr;
    > int status;
    >
    > l_tevent1.sigev_notify = SIGEV_THREAD;
    > l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    > l_tevent1.sigev_notify_function = Test;
    > l_tevent1.sigev_notify_attributes = NULL;
    > l_tevent1.sigev_signo = SIGRTMIN;
    > l_timer_spec1.it_interval.tv_sec = 2;
    > l_timer_spec1.it_interval.tv_nsec = 0;
    > //set subsequent timer intervals
    > l_timer_spec1.it_value.tv_sec = 2;
    > l_timer_spec1.it_value.tv_nsec = 0;
    >
    > //create timer
    > if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    > {
    > status = 1;
    > }
    >
    > if (status == 0)
    > {
    > if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    > {
    > status = 1;
    > }
    > }
    >
    > ptr = malloc(1000000);
    >
    > if (ptr == NULL)
    > printf("NULL PTR\n");
    >
    > counter++;
    >
    > Exit(0);
    > }
    >
    > Now I know this code snipet is pretty useless but it was the result of
    > troubleshooting a problem. When the malloc fails the timer stops
    > operating as expected. After some research it appears that when malloc
    > fails, returns NULL, due to not enough resources it actually marks all
    > the available memory as allocated. Due to this the timer can't start
    > the thread when it pops. So my question is what, if anything, does the
    > standard have to say about the behavior of malloc in this situation. Is
    > this behavior allowed and if so is it common. It seems to me that there
    > are many more gracefull ways for this to fail.


    How do you know that the standard C library function malloc() is doing
    what you say it is? How do you know it is not the behavior of your
    proprietary commercial operating system?

    Your program is littered with things that do not exist in standard C.
    C does not know or care about "timers popping" or "threads".

    You don't even have convincing proof that the failed memory allocation
    is at fault, and in fact you can't prove that for sure in a strictly
    conforming program. Nevertheless, you could try. When the attempt to
    allocate 1,000,000 bytes fails, what is the result if you immediately
    try a smaller allocation, say 1 byte? Without the threads and popping
    timers.

    I'd suggest you talk to Green Hills technical support. You have an
    implementation specific issue, not a language one.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Feb 28, 2006
    #2
    1. Advertising

  3. gooch

    gooch Guest

    Jack Klein wrote:
    > On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote in
    > comp.lang.c:
    >
    > > I originally posted the following code in a group discussing threads
    > > but after further research I think I have a c question about the code.
    > > I know there are a couple of non standard c includes here and the POSIX
    > > stuff is non standard but this is how I stumbled onto this question.
    > >
    > > #include <INTEGRITY.h>
    > > #include <stdlib.h>
    > > #include <stdio.h>
    > > #include <pthread.h>
    > > #include <signal.h>
    > > #include <time.h>
    > >
    > > timer_t l_timer_2;
    > > int counter =0;
    > >
    > > //void Test(union sigval sigval)
    > > void Test (union sigval sigval)
    > > {
    > > printf("Count\n");
    > > counter++;
    > >
    > > return;
    > > }
    > >
    > >
    > > int main()
    > > {
    > > struct itimerspec l_timer_spec1;
    > > struct sigevent l_tevent1;
    > > int *ptr;
    > > int status;
    > >
    > > l_tevent1.sigev_notify = SIGEV_THREAD;
    > > l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    > > l_tevent1.sigev_notify_function = Test;
    > > l_tevent1.sigev_notify_attributes = NULL;
    > > l_tevent1.sigev_signo = SIGRTMIN;
    > > l_timer_spec1.it_interval.tv_sec = 2;
    > > l_timer_spec1.it_interval.tv_nsec = 0;
    > > //set subsequent timer intervals
    > > l_timer_spec1.it_value.tv_sec = 2;
    > > l_timer_spec1.it_value.tv_nsec = 0;
    > >
    > > //create timer
    > > if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    > > {
    > > status = 1;
    > > }
    > >
    > > if (status == 0)
    > > {
    > > if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    > > {
    > > status = 1;
    > > }
    > > }
    > >
    > > ptr = malloc(1000000);
    > >
    > > if (ptr == NULL)
    > > printf("NULL PTR\n");
    > >
    > > counter++;
    > >
    > > Exit(0);
    > > }
    > >
    > > Now I know this code snipet is pretty useless but it was the result of
    > > troubleshooting a problem. When the malloc fails the timer stops
    > > operating as expected. After some research it appears that when malloc
    > > fails, returns NULL, due to not enough resources it actually marks all
    > > the available memory as allocated. Due to this the timer can't start
    > > the thread when it pops. So my question is what, if anything, does the
    > > standard have to say about the behavior of malloc in this situation. Is
    > > this behavior allowed and if so is it common. It seems to me that there
    > > are many more gracefull ways for this to fail.

    >
    > How do you know that the standard C library function malloc() is doing
    > what you say it is? How do you know it is not the behavior of your
    > proprietary commercial operating system?
    >
    > Your program is littered with things that do not exist in standard C.
    > C does not know or care about "timers popping" or "threads".
    >
    > You don't even have convincing proof that the failed memory allocation
    > is at fault, and in fact you can't prove that for sure in a strictly
    > conforming program.


    Upon entering malloc a resource analyzer shows much memory available.
    Once malloc fails 100% of resources are utilized. Proof enough for you.

    >Nevertheless, you could try. When the attempt to
    > allocate 1,000,000 bytes fails, what is the result if you immediately
    > try a smaller allocation, say 1 byte? Without the threads and popping
    > timers.
    >
    > I'd suggest you talk to Green Hills technical support. You have an
    > implementation specific issue, not a language one.
    >


    My question is language specific. Ignore the code if you would like to
    and just read the question but the question has nothing to do with the
    implementation.
    gooch, Feb 28, 2006
    #3
  4. gooch

    pemo Guest

    gooch wrote:
    > I originally posted the following code in a group discussing threads
    > but after further research I think I have a c question about the code.
    > I know there are a couple of non standard c includes here and the
    > POSIX stuff is non standard but this is how I stumbled onto this
    > question.
    >
    > #include <INTEGRITY.h>
    > #include <stdlib.h>
    > #include <stdio.h>
    > #include <pthread.h>
    > #include <signal.h>
    > #include <time.h>
    >
    > timer_t l_timer_2;
    > int counter =0;
    >
    > //void Test(union sigval sigval)
    > void Test (union sigval sigval)
    > {
    > printf("Count\n");
    > counter++;
    >
    > return;
    > }
    >
    >
    > int main()
    > {
    > struct itimerspec l_timer_spec1;
    > struct sigevent l_tevent1;
    > int *ptr;
    > int status;
    >
    > l_tevent1.sigev_notify = SIGEV_THREAD;
    > l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    > l_tevent1.sigev_notify_function = Test;
    > l_tevent1.sigev_notify_attributes = NULL;
    > l_tevent1.sigev_signo = SIGRTMIN;
    > l_timer_spec1.it_interval.tv_sec = 2;
    > l_timer_spec1.it_interval.tv_nsec = 0;
    > //set subsequent timer intervals
    > l_timer_spec1.it_value.tv_sec = 2;
    > l_timer_spec1.it_value.tv_nsec = 0;
    >
    > //create timer
    > if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    > {
    > status = 1;
    > }
    >
    > if (status == 0)
    > {
    > if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    > {
    > status = 1;
    > }
    > }
    >
    > ptr = malloc(1000000);
    >
    > if (ptr == NULL)
    > printf("NULL PTR\n");
    >
    > counter++;
    >
    > Exit(0);
    > }
    >
    > Now I know this code snipet is pretty useless but it was the result of
    > troubleshooting a problem. When the malloc fails the timer stops
    > operating as expected. After some research it appears that when malloc
    > fails, returns NULL, due to not enough resources it actually marks all
    > the available memory as allocated. Due to this the timer can't start
    > the thread when it pops.


    > So my question is what, if anything, does the standard have to say about
    > the behavior of malloc in this situation.


    > Is this behavior allowed and if so is it common. It seems to me that
    > there are many more gracefull ways for this to fail.


    From the c99 standard on malloc ...
    "If the space cannot be allocated, a null pointer is returned"

    And that's it.

    --
    ==============
    Not a pedant
    ==============
    pemo, Feb 28, 2006
    #4
  5. gooch

    gooch Guest

    pemo wrote:
    > gooch wrote:
    > > I originally posted the following code in a group discussing threads
    > > but after further research I think I have a c question about the code.
    > > I know there are a couple of non standard c includes here and the
    > > POSIX stuff is non standard but this is how I stumbled onto this
    > > question.
    > >
    > > #include <INTEGRITY.h>
    > > #include <stdlib.h>
    > > #include <stdio.h>
    > > #include <pthread.h>
    > > #include <signal.h>
    > > #include <time.h>
    > >
    > > timer_t l_timer_2;
    > > int counter =0;
    > >
    > > //void Test(union sigval sigval)
    > > void Test (union sigval sigval)
    > > {
    > > printf("Count\n");
    > > counter++;
    > >
    > > return;
    > > }
    > >
    > >
    > > int main()
    > > {
    > > struct itimerspec l_timer_spec1;
    > > struct sigevent l_tevent1;
    > > int *ptr;
    > > int status;
    > >
    > > l_tevent1.sigev_notify = SIGEV_THREAD;
    > > l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    > > l_tevent1.sigev_notify_function = Test;
    > > l_tevent1.sigev_notify_attributes = NULL;
    > > l_tevent1.sigev_signo = SIGRTMIN;
    > > l_timer_spec1.it_interval.tv_sec = 2;
    > > l_timer_spec1.it_interval.tv_nsec = 0;
    > > //set subsequent timer intervals
    > > l_timer_spec1.it_value.tv_sec = 2;
    > > l_timer_spec1.it_value.tv_nsec = 0;
    > >
    > > //create timer
    > > if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    > > {
    > > status = 1;
    > > }
    > >
    > > if (status == 0)
    > > {
    > > if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    > > {
    > > status = 1;
    > > }
    > > }
    > >
    > > ptr = malloc(1000000);
    > >
    > > if (ptr == NULL)
    > > printf("NULL PTR\n");
    > >
    > > counter++;
    > >
    > > Exit(0);
    > > }
    > >
    > > Now I know this code snipet is pretty useless but it was the result of
    > > troubleshooting a problem. When the malloc fails the timer stops
    > > operating as expected. After some research it appears that when malloc
    > > fails, returns NULL, due to not enough resources it actually marks all
    > > the available memory as allocated. Due to this the timer can't start
    > > the thread when it pops.

    >
    > > So my question is what, if anything, does the standard have to say about
    > > the behavior of malloc in this situation.

    >
    > > Is this behavior allowed and if so is it common. It seems to me that
    > > there are many more gracefull ways for this to fail.

    >
    > From the c99 standard on malloc ...
    > "If the space cannot be allocated, a null pointer is returned"
    >
    > And that's it.


    Thanks. That is what I was looking for.
    gooch, Feb 28, 2006
    #5
  6. gooch

    Al Balmer Guest

    On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote:

    > After some research it appears that when malloc
    >fails, returns NULL, due to not enough resources it actually marks all
    >the available memory as allocated. Due to this the timer can't start
    >the thread when it pops. So my question is what, if anything, does the
    >standard have to say about the behavior of malloc in this situation.


    Nothing, except that the function returns NULL.

    > Is
    >this behavior allowed and if so is it common. It seems to me that there
    >are many more gracefull ways for this to fail.


    Apparently it's allowed, but I don't think it's common, nor does it
    make sense. Systems that I've worked with don't use any memory on a
    failed allocation.

    It's a quality of implementation issue - talk to the vendor.

    --
    Al Balmer
    Sun City, AZ
    Al Balmer, Feb 28, 2006
    #6
  7. gooch

    gooch Guest

    Al Balmer wrote:
    > On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote:
    >
    > > After some research it appears that when malloc
    > >fails, returns NULL, due to not enough resources it actually marks all
    > >the available memory as allocated. Due to this the timer can't start
    > >the thread when it pops. So my question is what, if anything, does the
    > >standard have to say about the behavior of malloc in this situation.

    >
    > Nothing, except that the function returns NULL.
    >
    > > Is
    > >this behavior allowed and if so is it common. It seems to me that there
    > >are many more gracefull ways for this to fail.

    >
    > Apparently it's allowed, but I don't think it's common, nor does it
    > make sense. Systems that I've worked with don't use any memory on a
    > failed allocation.
    >
    > It's a quality of implementation issue - talk to the vendor.
    >

    Yeah, I have already contacted the vendor but I was just curious as to
    what the standard has to say about this.

    Thanks for the input.
    gooch, Feb 28, 2006
    #7
  8. gooch

    Jordan Abel Guest

    On 2006-02-28, gooch <> wrote:
    >
    > Jack Klein wrote:
    >> On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote in
    >> comp.lang.c:
    >>
    >> > I originally posted the following code in a group discussing threads
    >> > but after further research I think I have a c question about the code.
    >> > I know there are a couple of non standard c includes here and the POSIX
    >> > stuff is non standard but this is how I stumbled onto this question.
    >> >
    >> > #include <INTEGRITY.h>
    >> > #include <stdlib.h>
    >> > #include <stdio.h>
    >> > #include <pthread.h>
    >> > #include <signal.h>
    >> > #include <time.h>
    >> >
    >> > timer_t l_timer_2;
    >> > int counter =0;
    >> >
    >> > //void Test(union sigval sigval)
    >> > void Test (union sigval sigval)
    >> > {
    >> > printf("Count\n");
    >> > counter++;
    >> >
    >> > return;
    >> > }
    >> >
    >> >
    >> > int main()
    >> > {
    >> > struct itimerspec l_timer_spec1;
    >> > struct sigevent l_tevent1;
    >> > int *ptr;
    >> > int status;
    >> >
    >> > l_tevent1.sigev_notify = SIGEV_THREAD;
    >> > l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    >> > l_tevent1.sigev_notify_function = Test;
    >> > l_tevent1.sigev_notify_attributes = NULL;
    >> > l_tevent1.sigev_signo = SIGRTMIN;
    >> > l_timer_spec1.it_interval.tv_sec = 2;
    >> > l_timer_spec1.it_interval.tv_nsec = 0;
    >> > //set subsequent timer intervals
    >> > l_timer_spec1.it_value.tv_sec = 2;
    >> > l_timer_spec1.it_value.tv_nsec = 0;
    >> >
    >> > //create timer
    >> > if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    >> > {
    >> > status = 1;
    >> > }
    >> >
    >> > if (status == 0)
    >> > {
    >> > if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    >> > {
    >> > status = 1;
    >> > }
    >> > }
    >> >
    >> > ptr = malloc(1000000);
    >> >
    >> > if (ptr == NULL)
    >> > printf("NULL PTR\n");
    >> >
    >> > counter++;
    >> >
    >> > Exit(0);
    >> > }
    >> >
    >> > Now I know this code snipet is pretty useless but it was the result of
    >> > troubleshooting a problem. When the malloc fails the timer stops
    >> > operating as expected. After some research it appears that when malloc
    >> > fails, returns NULL, due to not enough resources it actually marks all
    >> > the available memory as allocated. Due to this the timer can't start
    >> > the thread when it pops. So my question is what, if anything, does the
    >> > standard have to say about the behavior of malloc in this situation. Is
    >> > this behavior allowed and if so is it common. It seems to me that there
    >> > are many more gracefull ways for this to fail.

    >>
    >> How do you know that the standard C library function malloc() is doing
    >> what you say it is? How do you know it is not the behavior of your
    >> proprietary commercial operating system?
    >>
    >> Your program is littered with things that do not exist in standard C.
    >> C does not know or care about "timers popping" or "threads".
    >>
    >> You don't even have convincing proof that the failed memory allocation
    >> is at fault, and in fact you can't prove that for sure in a strictly
    >> conforming program.

    >
    > Upon entering malloc a resource analyzer shows much memory available.
    > Once malloc fails 100% of resources are utilized. Proof enough for you.


    No, that's not "proof enough" - no-one here knows how their resource
    analyzer works. I'll tell you how a typical malloc implementation works,
    though - it grabs a large chunk of memory from the system all at once
    and passes it out in smaller chunks to each malloc request. It's
    possible that the large chunk might be seen by the "resource analyzer"
    as being utilized.

    >>Nevertheless, you could try. When the attempt to
    >> allocate 1,000,000 bytes fails, what is the result if you immediately
    >> try a smaller allocation, say 1 byte? Without the threads and popping
    >> timers.
    >>
    >> I'd suggest you talk to Green Hills technical support. You have an
    >> implementation specific issue, not a language one.
    >>

    >
    > My question is language specific.


    It's specific to a particular implementation of the language. Which
    makes it their problem, and not ours.

    > Ignore the code if you would like to and just read the question but
    > the question has nothing to do with the implementation.
    >
    Jordan Abel, Feb 28, 2006
    #8
  9. gooch

    gooch Guest

    Jordan Abel wrote:
    > On 2006-02-28, gooch <> wrote:
    > >
    > > Jack Klein wrote:
    > >> On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote in
    > >> comp.lang.c:
    > >>
    > >> > I originally posted the following code in a group discussing threads
    > >> > but after further research I think I have a c question about the code.
    > >> > I know there are a couple of non standard c includes here and the POSIX
    > >> > stuff is non standard but this is how I stumbled onto this question.
    > >> >
    > >> > #include <INTEGRITY.h>
    > >> > #include <stdlib.h>
    > >> > #include <stdio.h>
    > >> > #include <pthread.h>
    > >> > #include <signal.h>
    > >> > #include <time.h>
    > >> >
    > >> > timer_t l_timer_2;
    > >> > int counter =0;
    > >> >
    > >> > //void Test(union sigval sigval)
    > >> > void Test (union sigval sigval)
    > >> > {
    > >> > printf("Count\n");
    > >> > counter++;
    > >> >
    > >> > return;
    > >> > }
    > >> >
    > >> >
    > >> > int main()
    > >> > {
    > >> > struct itimerspec l_timer_spec1;
    > >> > struct sigevent l_tevent1;
    > >> > int *ptr;
    > >> > int status;
    > >> >
    > >> > l_tevent1.sigev_notify = SIGEV_THREAD;
    > >> > l_tevent1.sigev_value.sival_ptr = &l_timer_2;
    > >> > l_tevent1.sigev_notify_function = Test;
    > >> > l_tevent1.sigev_notify_attributes = NULL;
    > >> > l_tevent1.sigev_signo = SIGRTMIN;
    > >> > l_timer_spec1.it_interval.tv_sec = 2;
    > >> > l_timer_spec1.it_interval.tv_nsec = 0;
    > >> > //set subsequent timer intervals
    > >> > l_timer_spec1.it_value.tv_sec = 2;
    > >> > l_timer_spec1.it_value.tv_nsec = 0;
    > >> >
    > >> > //create timer
    > >> > if (timer_create(CLOCK_REALTIME, &l_tevent1, &l_timer_2) < 0)
    > >> > {
    > >> > status = 1;
    > >> > }
    > >> >
    > >> > if (status == 0)
    > >> > {
    > >> > if (timer_settime(l_timer_2, 0, &l_timer_spec1, NULL) < 0 )
    > >> > {
    > >> > status = 1;
    > >> > }
    > >> > }
    > >> >
    > >> > ptr = malloc(1000000);
    > >> >
    > >> > if (ptr == NULL)
    > >> > printf("NULL PTR\n");
    > >> >
    > >> > counter++;
    > >> >
    > >> > Exit(0);
    > >> > }
    > >> >
    > >> > Now I know this code snipet is pretty useless but it was the result of
    > >> > troubleshooting a problem. When the malloc fails the timer stops
    > >> > operating as expected. After some research it appears that when malloc
    > >> > fails, returns NULL, due to not enough resources it actually marks all
    > >> > the available memory as allocated. Due to this the timer can't start
    > >> > the thread when it pops. So my question is what, if anything, does the
    > >> > standard have to say about the behavior of malloc in this situation. Is
    > >> > this behavior allowed and if so is it common. It seems to me that there
    > >> > are many more gracefull ways for this to fail.
    > >>
    > >> How do you know that the standard C library function malloc() is doing
    > >> what you say it is? How do you know it is not the behavior of your
    > >> proprietary commercial operating system?
    > >>
    > >> Your program is littered with things that do not exist in standard C.
    > >> C does not know or care about "timers popping" or "threads".
    > >>
    > >> You don't even have convincing proof that the failed memory allocation
    > >> is at fault, and in fact you can't prove that for sure in a strictly
    > >> conforming program.

    > >
    > > Upon entering malloc a resource analyzer shows much memory available.
    > > Once malloc fails 100% of resources are utilized. Proof enough for you.

    >
    > No, that's not "proof enough" - no-one here knows how their resource
    > analyzer works. I'll tell you how a typical malloc implementation works,
    > though - it grabs a large chunk of memory from the system all at once
    > and passes it out in smaller chunks to each malloc request. It's
    > possible that the large chunk might be seen by the "resource analyzer"
    > as being utilized.
    >
    > >>Nevertheless, you could try. When the attempt to
    > >> allocate 1,000,000 bytes fails, what is the result if you immediately
    > >> try a smaller allocation, say 1 byte? Without the threads and popping
    > >> timers.
    > >>
    > >> I'd suggest you talk to Green Hills technical support. You have an
    > >> implementation specific issue, not a language one.
    > >>

    > >
    > > My question is language specific.

    >
    > It's specific to a particular implementation of the language. Which
    > makes it their problem, and not ours.


    No my question was what does the standard have to say about the
    behavior of malloc if it fails, if anything. This question makes no
    assumtion about any implementation. Perhaps I could have worded the
    question a little clearer but it is not an implementation specific
    question.
    gooch, Feb 28, 2006
    #9
  10. gooch

    Al Balmer Guest

    On 28 Feb 2006 12:44:51 -0800, "gooch" <> wrote:

    >> It's specific to a particular implementation of the language. Which
    >> makes it their problem, and not ours.

    >
    >No my question was what does the standard have to say about the
    >behavior of malloc if it fails, if anything. This question makes no
    >assumtion about any implementation. Perhaps I could have worded the
    >question a little clearer but it is not an implementation specific
    >question.


    While we're bashing you <g>, a word about editing. At least 100 lines
    of your post was unneeded for your reply.

    --
    Al Balmer
    Sun City, AZ
    Al Balmer, Feb 28, 2006
    #10
  11. gooch

    gooch Guest


    >
    > While we're bashing you <g>, a word about editing. At least 100 lines
    > of your post was unneeded for your reply.
    >

    Sorry about that. I will keep that in mind. Thanks again for the
    response earlier.
    gooch, Feb 28, 2006
    #11
  12. gooch wrote:
    > Al Balmer wrote:
    >>
    >> While we're bashing you <g>, a word about editing. At least 100 lines
    >> of your post was unneeded for your reply.
    >>

    > Sorry about that. I will keep that in mind. Thanks again for the
    > response earlier.


    And while we're still at it: ;o)

    Do not snip attribution lines -- it's important to know who said what.

    Keep up the good work!

    --
    BR, Vladimir

    How come only your friends step on your new white sneakers?
    Vladimir S. Oka, Feb 28, 2006
    #12
  13. In article <>,
    "gooch" <> wrote:

    > Al Balmer wrote:
    > > On 27 Feb 2006 16:38:01 -0800, "gooch" <> wrote:
    > >
    > > > After some research it appears that when malloc
    > > >fails, returns NULL, due to not enough resources it actually marks all
    > > >the available memory as allocated. Due to this the timer can't start
    > > >the thread when it pops. So my question is what, if anything, does the
    > > >standard have to say about the behavior of malloc in this situation.

    > >
    > > Nothing, except that the function returns NULL.
    > >
    > > > Is
    > > >this behavior allowed and if so is it common. It seems to me that there
    > > >are many more gracefull ways for this to fail.

    > >
    > > Apparently it's allowed, but I don't think it's common, nor does it
    > > make sense. Systems that I've worked with don't use any memory on a
    > > failed allocation.
    > >
    > > It's a quality of implementation issue - talk to the vendor.
    > >

    > Yeah, I have already contacted the vendor but I was just curious as to
    > what the standard has to say about this.


    According to the C Standard, _any_ call to malloc could fail, returning
    NULL. The rest is "quality of implementation". But if you have enough
    memory for say malloc (900000) to succeed, and malloc (1000000) fails,
    and _because of that_ malloc (10000) fails, that would be "low quality
    of implementation".
    Christian Bau, Mar 1, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ilias Lazaridis
    Replies:
    0
    Views:
    571
    Ilias Lazaridis
    Feb 1, 2005
  2. John Eskie

    Non-failure guarantied malloc/new

    John Eskie, Dec 24, 2003, in forum: C++
    Replies:
    11
    Views:
    592
    Jeff Schwab
    Dec 26, 2003
  3. Replies:
    0
    Views:
    470
  4. Sandy Beech

    struct/malloc failure

    Sandy Beech, Oct 16, 2010, in forum: C Programming
    Replies:
    3
    Views:
    694
    Nick Keighley
    Oct 17, 2010
  5. jay
    Replies:
    26
    Views:
    235
    James Kuyper
    Apr 3, 2014
Loading...

Share This Page