How to make malloc() fail ?

[niranjan.singh]

This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....
regards

[santosh]

ni************@ gmail.com wrote:

This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....

In statement:

ptr = malloc(N);

malloc will return NULL when it's not able to allocate N bytes of
storage.

Ways to force malloc to fail in it's allocation are system specific,
so asking in an appropriate group would be more suitable.

<OT>
There are "stress testing" programs which can simulate a low free
memory condition. Alternatively your operating system might have
facilities for enforcing per user or per program quotas for memory
allocation.
</OT>

[Richard Heathfield]

santosh said:

ni************@ gmail.com wrote:

>This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....

In statement:

ptr = malloc(N);

malloc will return NULL when it's not able to allocate N bytes of
storage.

Ways to force malloc to fail in it's allocation are system specific,
so asking in an appropriate group would be more suitable.

You see, this is what I don't like about this group. "Always with you it
cannot be done", as Yoda rightly said.

Okay, in the obvious sense, you're right that you can't force malloc to
fail at your command, in the general case (requests for 0xFFFFFFFF
bytes don't count, of course - we want a more general solution than
that).

But it seems to me that this isn't really what the OP wants, despite the
wording of his question. What he wants is a software environment in
which memory allocation failures can be simulated for testing purposes.
And that *is* possible within ISO C. I know because I've done it, and
quite recently too (like, within the last month or so).

I'm not going to explain how, because I wouldn't want to distract the OP
from focusing on the more basic skills he should be developing before
embarking on something as intellectually challenging as programming.

But I invite you to consider the problem yourself, as an exercise in
creative thinking. If you trust what I say (and I suspect that you
might), you can reason thusly: "there exists at least one solution to
the problem of testing allocation failure paths in portable C code;
knowing this, and knowing that I'm no fool, I ought to be able to find
a solution myself - and maybe it will be useful in my own programming".

You know it won't be obvious. You know it will involve a little effort.
But you also know that, if Richard can do it, it can't be *that* hard.

I am beginning to despair of comp.lang.c. :-(

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Richard Heathfield wrote:

I apologise in advance if this post appears multiple times. Google has
been wretched to use today.

santosh said:

ni************@ gmail.com wrote:

>
This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....

In statement:

ptr = malloc(N);

malloc will return NULL when it's not able to allocate N bytes of
storage.

Ways to force malloc to fail in it's allocation are system specific,
so asking in an appropriate group would be more suitable.

You see, this is what I don't like about this group. "Always with you it
cannot be done", as Yoda rightly said.

Okay, in the obvious sense, you're right that you can't force malloc to
fail at your command, in the general case (requests for 0xFFFFFFFF
bytes don't count, of course - we want a more general solution than
that).

But it seems to me that this isn't really what the OP wants, despite the
wording of his question. What he wants is a software environment in
which memory allocation failures can be simulated for testing purposes.
And that *is* possible within ISO C. I know because I've done it, and
quite recently too (like, within the last month or so).

Yes. That's why I said "ways to force malloc", which isn't, AFAIK,
possible within portable C. As you've noted, ways to simulate
allocation failures *are* possible within Standard C.

I still don't really understand exactly what the OP wants to know
about. In hindsight, I should have pointed out to the OP that it's
possible to simulate memory allocation failures with just Standard C,
but since I myself usually rely on external programs for this purpose,
the fact skipped my mind.

<snip>

I am beginning to despair of comp.lang.c. :-(

I still consider this an excellent group for C, but then again, I've
been here only for two years, so I don't have a first hand experience
of it's heydays.

[Richard Heathfield]

Keith Thompson said:

<snip>

If you're trying to *cause* malloc to fail, the obvious way to do it
is to request some huge amount of memory, repeatedly if necessary.

Fortunately, there is also at least one non-obvious way. :-)

(And yes, it involves cheating, but *not* by resorting to non-portable
code.)

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[user923005]

On Jul 17, 4:03 am, Richard Heathfield <[e-mail].i nvalidwrote:

santosh said:

niranjan.si...@ gmail.com wrote:

This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....

In statement:

ptr = malloc(N);

malloc will return NULL when it's not able to allocate N bytes of
storage.

Ways to force malloc to fail in it's allocation are system specific,
so asking in an appropriate group would be more suitable.

You see, this is what I don't like about this group. "Always with you it
cannot be done", as Yoda rightly said.

Okay, in the obvious sense, you're right that you can't force malloc to
fail at your command, in the general case (requests for 0xFFFFFFFF
bytes don't count, of course - we want a more general solution than
that).

But it seems to me that this isn't really what the OP wants, despite the
wording of his question. What he wants is a software environment in
which memory allocation failures can be simulated for testing purposes.
And that *is* possible within ISO C. I know because I've done it, and
quite recently too (like, within the last month or so).

I'm not going to explain how, because I wouldn't want to distract the OP
from focusing on the more basic skills he should be developing before
embarking on something as intellectually challenging as programming.

But I invite you to consider the problem yourself, as an exercise in
creative thinking. If you trust what I say (and I suspect that you
might), you can reason thusly: "there exists at least one solution to
the problem of testing allocation failure paths in portable C code;
knowing this, and knowing that I'm no fool, I ought to be able to find
a solution myself - and maybe it will be useful in my own programming".

You know it won't be obvious. You know it will involve a little effort.
But you also know that, if Richard can do it, it can't be *that* hard.

I am beginning to despair of comp.lang.c. :-(

I use this to create low memory situations.
You can do it all in a big clump, or start lots of them with smaller
mouthfuls.
Of course, to find the exact failure point, a binary search is what is
wanted.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static char string[32767];
int main(int argc, char **argv)
{
size_t megabytes = 1024u * 1024u;
size_t megs = 256;
size_t memreq;
char *waster;
if (argc 1)
megs = atoi(argv[1]);
if (megs == 0)
megs = 256;

memreq = megs * megabytes;
waster = malloc(memreq);
if (waster == NULL) {
puts("Memory allocation failed");
} else {
printf("Press the <Enterkey to release %u megs memory\n",
(unsigned) megs);
fgets(string, sizeof string, stdin);
free(waster);
}
return 0;
}

[Richard Heathfield]

user923005 said:

<snip>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static char string[32767];
int main(int argc, char **argv)
{
size_t megabytes = 1024u * 1024u;

1024u * 1024u is not guaranteed to fit in a size_t, so you might end up
with a lower value therein (e.g. 0, if size_t is 16 bits).

size_t megs = 256;
size_t memreq;
char *waster;
if (argc 1)
megs = atoi(argv[1]);

I recommend strtoul(argv[1], NULL, 10) instead of atoi(argv[1]).

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Daniel Rudy]

At about the time of 7/17/2007 3:36 AM, ni************@ gmail.com stated
the following:

This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....
regards

something like this:

ptr = malloc(0xFFFFFF FF);

That will usually cause the allocation to fail...it might also cause the
host OS to abort the program too. I know that FreeBSD does not give a
failure indication, the OS kills the program.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

[Doug]

On Jul 17, 12:03 pm, Richard Heathfield <[e-mail].i nvalidwrote:

santosh said:

niranjan.si...@ gmail.com wrote:

This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....

In statement:

ptr = malloc(N);

malloc will return NULL when it's not able to allocate N bytes of
storage.

Ways to force malloc to fail in it's allocation are system specific,
so asking in an appropriate group would be more suitable.

You see, this is what I don't like about this group. "Always with you it
cannot be done", as Yoda rightly said.

<snip>

I'm not going to explain how, because I wouldn't want to distract the OP
from focusing on the more basic skills he should be developing before
embarking on something as intellectually challenging as programming.

You see, this is what I don;t like about this group. "Always with you
it must be condescending."

I'm not sure why you feel you have to comment on the ability of the
OP. Stinks of pure arrogance to me.

What is clc for, if not to ask questions? You yourself have said this
was on-topic. Why not give an answer, instead of your usual b.s. "I
know but I'm not telling you"?

Please get over yourself. If you're not going to help, be quiet. And
please stop answering spam.

To the OP - this can be done, but is probably best done in a platform-
specific manner. Try asking in a group specific to your platform, or
come back if you want a general solution.

Doug

P.S. My apologies if someone else is posting in RH's name

[Richard Heathfield]

Doug said:

On Jul 17, 12:03 pm, Richard Heathfield <[e-mail].i nvalidwrote:

>>

niranjan.si...@ gmail.com wrote:
This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....

<snip>

>

>I'm not going to explain how, because I wouldn't want to distract the
OP from focusing on the more basic skills he should be developing
before embarking on something as intellectually challenging as
programming.

You see, this is what I don;t like about this group. "Always with you
it must be condescending."

I'm not sure why you feel you have to comment on the ability of the
OP. Stinks of pure arrogance to me.

Well, it wasn't intended that way, but how you interpret it is your
affair, not mine.

What is clc for, if not to ask questions?

It's for discussions about C programming. The whole question-answer
thing is, in my view, merely one way in which discussions start. It is
true that it happens to be the most common way. But if it were not,
then some other way would be, and by your apparent reasoning we'd all
presume /that/ way best to describe the raison d'etre of this group.

You yourself have said this
was on-topic. Why not give an answer, instead of your usual b.s. "I
know but I'm not telling you"?

Usual? It is actually quite rare for me to answer in such a way, as you
ought to know if you believe yourself to be in a position to comment on
my "usual" style. If you truly believe that what I usually post is
"b.s.", then would it not have made sense for you to killfile me a long
time ago?

Please get over yourself. If you're not going to help, be quiet.

1) I have the same freedom to post here as anyone else.
2) I didn't see you providing an answer to his question, so your
position is somewhat hypocritical, is it not?
3) (This is the one you won't believe, but so be it.) I *was* actually
trying to help the OP, by suggesting that he focuses on developing his
ability to express his ideas cogently; if he takes my advice, this will
have a very positive effect on his ability to write computer programs.

And please stop answering spam.

It is true that I occasionally post replies to spam, although it is
rare. I have the same freedom to do that as you have to ask me to stop.
I rarely use that freedom, but yes, I do use it sometimes. That's up to
me. If you don't like what I write, well, that's up to you.

And now I have my own suggestion to make to you: if you must tell other
people how to behave, it might be as well for you to be prepared for
the possibility that those others might not see the world the way you
do. For example, you say you found my tone arrogant, and yet I know
that I did not intend to convey arrogance. That suggests that I may
need to pay closer attention to my tone. Likewise, however, I found
your reply to be self-serving, hypocritical, and non-constructive. If
that was not the kind of reply you intended to write, perhaps you, too,
need to pay closer attention to your tone.

I am not aware that you have been particularly active in providing help
to those who seek it in this forum, or that you have contributed very
much to the discussions here in comp.lang.c. It's easy to snipe from
the sidelines. If you want me to take your criticisms seriously, *get
involved*. Taking part in discussions, answering questions, getting
tangled up in amicable fights about C, and taking one's lumps when one
gets it wrong, are all part of the rough and tumble of daily
comp.lang.c life, and those who are actively involved are far more
likely to be taken seriously than those who are not.

>
To the OP - this can be done, but is probably best done in a platform-
specific manner. Try asking in a group specific to your platform, or
come back if you want a general solution.

<sarcasm>Very good.</sarcasmAnd what did that add to what has already
been said elsethread?

Doug

P.S. My apologies if someone else is posting in RH's name

This P.S. suggests that you are perfectly well aware that my "usual"
tone is not what you claimed it to be, earlier in your article.

FCOL, furrfu, etc.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999