malloc behavior on failure

[gooch]

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.

 

[Jack Klein]

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.

 

[gooch]

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.

 

[pemo]

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.

 

[gooch]

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.

 

[Al Balmer]

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.

 

[gooch]

Nothing, except that the function returns NULL.


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.

 

[Jordan Abel]

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.

My question is language specific.

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

 

[gooch]

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.


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.

 

[Al Balmer]

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.

 

[gooch]

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.

 

[Vladimir S. Oka]

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!

 

[Christian Bau]

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".