469,271 Members | 1,481 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

How to make malloc() fail ?

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

Jul 17 '07 #1
34 12006
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>

Jul 17 '07 #2
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
Jul 17 '07 #3
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.

Jul 17 '07 #4
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
Jul 17 '07 #5
On Jul 17, 4:03 am, Richard Heathfield <r...@see.sig.invalidwrote:
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;
}

Jul 18 '07 #6
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
Jul 18 '07 #7
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(0xFFFFFFFF);

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
Jul 18 '07 #8
On Jul 17, 12:03 pm, Richard Heathfield <r...@see.sig.invalidwrote:
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

Jul 18 '07 #9
Doug said:
On Jul 17, 12:03 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>>
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
Jul 18 '07 #10
On Wednesday 18 Jul 2007 1:15 pm, in comp.lang.c, Daniel Rudy
<sp******@spamthis.netwrote:
Message ID: <Cy****************@newssvr13.news.prodigy.net>
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(0xFFFFFFFF);

That will usually cause the allocation to fail...
Many modern workstations have 4 Gb or more of memory installed.
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.
That's why it's not possible within ISO C to cause malloc to reliably
fail. However you can use support code to simulate memory allocation
failures. The support code can be portable C.
Jul 18 '07 #11
santosh wrote:
On Wednesday 18 Jul 2007 1:15 pm, in comp.lang.c, Daniel Rudy
<sp******@spamthis.netwrote:
Message ID: <Cy****************@newssvr13.news.prodigy.net>
>>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(0xFFFFFFFF);

That will usually cause the allocation to fail...


Many modern workstations have 4 Gb or more of memory installed.
replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
<stdint.h>; size_t is not guaranteed to be unsigned), that's more
portable anyway - 64bit machines are real-world things already.

Other point if you actually want libc's malloc to fail or if you want to
verify the application's response to a failing malloc. for the latter
case try replacing libc's malloc by another function implementing the
same interface. There are ways to do so without or with little
modifications to the tested code.

bm
--
Bernhard Mueller
bernhard dot mueller at
Jul 22 '07 #12
Bernhard Mller wrote, On 22/07/07 20:24:

<snip>
replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
<stdint.h>; size_t is not guaranteed to be unsigned),
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.
--
Flash Gordon
Jul 22 '07 #13
Flash Gordon wrote:
Bernhard M羹ller wrote, On 22/07/07 20:24:

<snip>
>replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
<stdint.h>; size_t is not guaranteed to be unsigned),

Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.
It is guaranteed to be an unsigned integer type, which might or might not be
the type specified by "unsigned" (aka "unsigned int").
Jul 22 '07 #14
Harald van D議k wrote, On 22/07/07 21:08:
Flash Gordon wrote:
>Bernhard M羹ller wrote, On 22/07/07 20:24:

<snip>
>>replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
<stdint.h>; size_t is not guaranteed to be unsigned),
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.

It is guaranteed to be an unsigned integer type, which might or might not be
the type specified by "unsigned" (aka "unsigned int").
I meant an unsigned type, not unsigned int. I should have been clear.
--
Flash Gordon
Jul 22 '07 #15
Flash Gordon wrote:
Harald van D議k wrote, On 22/07/07 21:08:
>Flash Gordon wrote:
>>Bernhard M羹ller wrote, On 22/07/07 20:24:

<snip>

replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
<stdint.h>; size_t is not guaranteed to be unsigned),
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.

It is guaranteed to be an unsigned integer type, which might or might not
be the type specified by "unsigned" (aka "unsigned int").

I meant an unsigned type, not unsigned int. I should have been clear.
I know that's what you meant. I meant that it doesn't necessarily contradict
Bernhard M羹ller's claim.
Jul 23 '07 #16
On Mon, 23 Jul 2007 06:55:54 +0200, Harald van D議k wrote:
Flash Gordon wrote:
>Harald van D議k wrote, On 22/07/07 21:08:
>>Flash Gordon wrote:
Bernhard M羹ller wrote, On 22/07/07 20:24:

<snip>

replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
<stdint.h>; size_t is not guaranteed to be unsigned),
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.

It is guaranteed to be an unsigned integer type, which might or might not
be the type specified by "unsigned" (aka "unsigned int").

I meant an unsigned type, not unsigned int. I should have been clear.

I know that's what you meant. I meant that it doesn't necessarily contradict
Bernhard M羹ller's claim.
Even if size_t is an unsigned type other than unsigned int,
malloc((size_t)(-1)) does the same as malloc(SIZE_MAX). So I don't think
he meant size_t needn't be the type unsigned int, or the mention
of that macro would be irrelevant.

--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 24 '07 #17
Army1987 wrote:
On Mon, 23 Jul 2007 06:55:54 +0200, Harald van D議k wrote:
>Flash Gordon wrote:
>>Harald van D議k wrote, On 22/07/07 21:08:
Flash Gordon wrote:
Bernhard M羹ller wrote, On 22/07/07 20:24:
>
<snip>
>
>replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
><stdint.h>; size_t is not guaranteed to be unsigned),
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.

It is guaranteed to be an unsigned integer type, which might or might
not be the type specified by "unsigned" (aka "unsigned int").

I meant an unsigned type, not unsigned int. I should have been clear.

I know that's what you meant. I meant that it doesn't necessarily
contradict Bernhard M羹ller's claim.
Even if size_t is an unsigned type other than unsigned int,
malloc((size_t)(-1)) does the same as malloc(SIZE_MAX). So I don't think
he meant size_t needn't be the type unsigned int, or the mention
of that macro would be irrelevant.
I initially read it as
>>>>>replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
><stdint.h>); size_t is not guaranteed to be unsigned,
where it makes sense, but now re-reading it, I think you and Flash Gordon
may be right.
Jul 24 '07 #18
On Jul 18, 3:58 am, santosh <santosh....@gmail.comwrote:
On Wednesday 18 Jul 2007 1:15 pm, in comp.lang.c, Daniel Rudy<spamt...@spamthis.netwrote:

Message ID: <Cyjni.9381$eY.6...@newssvr13.news.prodigy.net>
At about the time of 7/17/2007 3:36 AM, niranjan.si...@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(0xFFFFFFFF);
That will usually cause the allocation to fail...

Many modern workstations have 4 Gb or more of memory installed.
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.

That's why it's not possible within ISO C to cause malloc to reliably
fail.
#include <stdio.h>
#include <stdlib.h>
/*
I would be keen to know about the implementation
where this code does not cause malloc() to fail.
P.S.:
It ain't a leak. It's a river.
*/
int main(void)
{
char *p;
for (;;) {
p = malloc((size_t) - 1);
if (p == 0) {
puts("I made malloc() fail.");
exit(EXIT_SUCCESS);
}
}
return 0;
}

However you can use support code to simulate memory allocation
failures. The support code can be portable C.
I think you're a bit off here.

Jul 24 '07 #19
user923005 wrote:
santosh wrote:
>Daniel Rudy wrote:
niranjan.si...@gmail.com wrote:

In what situation malloc gets fail.

something like this:
ptr = malloc(0xFFFFFFFF);

Many modern workstations have 4 Gb or more of memory installed.
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.

That's why it's not possible within ISO C to cause malloc to reliably
fail.

#include <stdio.h>
#include <stdlib.h>
/*
I would be keen to know about the implementation
where this code does not cause malloc() to fail.
P.S.:
It ain't a leak. It's a river.
*/
int main(void)
{
char *p;
for (;;) {
p = malloc((size_t) - 1);
if (p == 0) {
puts("I made malloc() fail.");
exit(EXIT_SUCCESS);
}
}
return 0;
}
You're right, thanks.

Jul 24 '07 #20
user923005 <dc*****@connx.comwrites:
/*
I would be keen to know about the implementation
where this code does not cause malloc() to fail.
P.S.:
It ain't a leak. It's a river.
*/
int main(void)
{
char *p;
for (;;) {
p = malloc((size_t) - 1);
if (p == 0) {
puts("I made malloc() fail.");
exit(EXIT_SUCCESS);
}
}
return 0;
}
This will make malloc fail on all implementations I am aware of.
However, it doesn't actually have the effect that I'd want for
testing. For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.
--
Ben Pfaff
http://benpfaff.org
Jul 24 '07 #21
Ben Pfaff said:

<snip>
For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.
What I do is arrange that, in D allocations from now, the next U
allocations will fail if they exceed B bytes. (Of course, they may fail
anyway, but I can't do anything about that.)

This can be done portably.

It's quite handy because it means that you can test the handling of
failures of "inner" allocs in ADT code - the "delay" facility allows
you to hop around the outer allocation of the metastructure and instead
put stress on the code that allocates memory for the containment of
whatever information it is that you're encapsulating.

--
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
Jul 24 '07 #22
Richard Heathfield <rj*@see.sig.invalidwrites:
What I do is arrange that, in D allocations from now, the next U
allocations will fail if they exceed B bytes. (Of course, they may fail
anyway, but I can't do anything about that.)

This can be done portably.
Please, tell us how. I have always done so by using a malloc
wrapper that does what I want. Not having to do that would be
convenient sometimes.
--
"I don't have C&V for that handy, but I've got Dan Pop."
--E. Gibbons
Jul 24 '07 #23
Ben Pfaff said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>What I do is arrange that, in D allocations from now, the next U
allocations will fail if they exceed B bytes. (Of course, they may
fail anyway, but I can't do anything about that.)

This can be done portably.

Please, tell us how.
Sorry to be so vague about this. Will it suffice to say that I use a
wrapper? If this disappoints you, I'm sorry, although of course the
wrapper is switchable-offable. I don't want to go into any more detail
than that in clc, at least not for the time being.

--
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
Jul 24 '07 #24
On Jul 24, 11:15 am, Ben Pfaff <b...@cs.stanford.eduwrote:
user923005 <dcor...@connx.comwrites:
/*
I would be keen to know about the implementation
where this code does not cause malloc() to fail.
P.S.:
It ain't a leak. It's a river.
*/
int main(void)
{
char *p;
for (;;) {
p = malloc((size_t) - 1);
if (p == 0) {
puts("I made malloc() fail.");
exit(EXIT_SUCCESS);
}
}
return 0;
}

This will make malloc fail on all implementations I am aware of.
However, it doesn't actually have the effect that I'd want for
testing. For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.
--
Ben Pfaffhttp://benpfaff.org
For that I use a binary search to allocate the largest possible
remaining block after the first failure.
Jul 25 '07 #25
user923005 <dc*****@connx.comwrites:
On Jul 24, 11:15 am, Ben Pfaff <b...@cs.stanford.eduwrote:
>This will make malloc fail on all implementations I am aware of.
However, it doesn't actually have the effect that I'd want for
testing. For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.

For that I use a binary search to allocate the largest possible
remaining block after the first failure.
Which won't help with implementations of malloc that allocate
memory in pools of equal-sized blocks: it's quite possible in
such an implementation to allocate 4 blocks of 16 bytes each,
even if you can't allocate a single block of 64 bytes;
conversely, you might be able to allocate one block of 64 bytes
but not one block of 16 bytes.

But I bet your approach works most of the time.
--
"You call this a *C* question? What the hell are you smoking?" --Kaz
Jul 25 '07 #26
On Jul 24, 7:45 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
user923005 <dcor...@connx.comwrites:
On Jul 24, 11:15 am, Ben Pfaff <b...@cs.stanford.eduwrote:
This will make malloc fail on all implementations I am aware of.
However, it doesn't actually have the effect that I'd want for
testing. For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.
For that I use a binary search to allocate the largest possible
remaining block after the first failure.

Which won't help with implementations of malloc that allocate
memory in pools of equal-sized blocks: it's quite possible in
such an implementation to allocate 4 blocks of 16 bytes each,
even if you can't allocate a single block of 64 bytes;
conversely, you might be able to allocate one block of 64 bytes
but not one block of 16 bytes.

But I bet your approach works most of the time.
For really cantankerous implementations you could have a loop that
allocates one byte at a time (until that fails) after the bsearch
block allocation.
Jul 25 '07 #27
user923005 <dc*****@connx.comwrites:
On Jul 24, 7:45 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
>user923005 <dcor...@connx.comwrites:
On Jul 24, 11:15 am, Ben Pfaff <b...@cs.stanford.eduwrote:
This will make malloc fail on all implementations I am aware of.
However, it doesn't actually have the effect that I'd want for
testing. For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.
For that I use a binary search to allocate the largest possible
remaining block after the first failure.

Which won't help with implementations of malloc that allocate
memory in pools of equal-sized blocks: it's quite possible in
such an implementation to allocate 4 blocks of 16 bytes each,
even if you can't allocate a single block of 64 bytes;
conversely, you might be able to allocate one block of 64 bytes
but not one block of 16 bytes.

But I bet your approach works most of the time.

For really cantankerous implementations you could have a loop that
allocates one byte at a time (until that fails) after the bsearch
block allocation.
That wouldn't help on the implementation I'm describing, because
it would only exhaust the pool for 1-byte allocations. There
could still be some room in pools for larger allocations.

Perhaps I can make the situation more concrete by referring you
to a very simple allocator that works this way, the file malloc.c
at:
http://www.stanford.edu/class/cs140/...s/src/threads/
It is not an ISO C compliant malloc, nor is it written in
strictly conforming ISO C, but it illustrates the principle at
work.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Jul 25 '07 #28
On Jul 24, 8:40 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
user923005 <dcor...@connx.comwrites:
On Jul 24, 7:45 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
user923005 <dcor...@connx.comwrites:
On Jul 24, 11:15 am, Ben Pfaff <b...@cs.stanford.eduwrote:
This will make malloc fail on all implementations I am aware of.
However, it doesn't actually have the effect that I'd want for
testing. For testing purposes, I want to make the next call to
malloc fail, or perhaps to make all future calls to malloc fail.
But I'd expect that on many implementations, code similar to the
above would typically call malloc(-1) once, which would fail
without actually allocating any memory, and then future calls to
malloc would succeed or fail in the same way as if I hadn't
called malloc(-1) at all.
For that I use a binary search to allocate the largest possible
remaining block after the first failure.
Which won't help with implementations of malloc that allocate
memory in pools of equal-sized blocks: it's quite possible in
such an implementation to allocate 4 blocks of 16 bytes each,
even if you can't allocate a single block of 64 bytes;
conversely, you might be able to allocate one block of 64 bytes
but not one block of 16 bytes.
But I bet your approach works most of the time.
For really cantankerous implementations you could have a loop that
allocates one byte at a time (until that fails) after the bsearch
block allocation.

That wouldn't help on the implementation I'm describing, because
it would only exhaust the pool for 1-byte allocations. There
could still be some room in pools for larger allocations.

Perhaps I can make the situation more concrete by referring you
to a very simple allocator that works this way, the file malloc.c
at:
http://www.stanford.edu/class/cs140/...s/src/threads/
It is not an ISO C compliant malloc, nor is it written in
strictly conforming ISO C, but it illustrates the principle at
work.
Maybe a custom solution like this then:

#include <stdlib.h>
void exhaust_bens_memory()
{
size_t blocksize = 2048;
while (blocksize) {
while (malloc(blocksize)) {;}
blocksize >>= 1;
}
}

Jul 25 '07 #29
it is really platform specific, for example in my system libc, malloc
has this implemetation:

....
/* why would you ever want a negative malloc, this would mean */
/* a very large positive number which can't be filled */

if ((int)nbytes < 0){
errno = ENOMEM;
return NULL;
}

....
so calling `malloc()' with negative argument will cause it to fall.

Jul 25 '07 #30
In article <11**********************@57g2000hsv.googlegroups. com>,
crox <cr*****@gmail.comwrote:
>it is really platform specific, for example in my system libc, malloc
has this implemetation:

...
/* why would you ever want a negative malloc, this would mean */
/* a very large positive number which can't be filled */

if ((int)nbytes < 0){
The argument to malloc() has type size_t, which is unsigned, so you
*can't* pass it a negative value. It may well be true that values
corresponding to negative ints are usually the result of a bug in the
program causing a negative value to be converted to a large size_t,
but I'm not sure why your code bothers to make this check, since if
requests for "very large" amounts of memory can't be filled, it will
fail anyway without the check.

I think the comment would be more accurate if it read "Why would you
ever want to malloc such a huge amount? It can't be done and is more
likely an erroneous attempt to malloc a negative size".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jul 25 '07 #31
On Jul 24, 3:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:
Ben Pfaff said:

Please, tell us how.

Sorry to be so vague about this. Will it suffice to say that I use a
wrapper?


How?
Assume that you have a program in which malloc is not wrappred.
How do you wrap it without going through and replacing all the calls
to
malloc? Sure

#define malloc wrap_malloc

will probably work, but you can't redefine a library function in
portable code.
(given that you have a wrapper function things are straightforward.
Store state as a global or pseudo-global (static in a module),
manipulate with wrap_malloc_change_state()
then the wrapper function will return NULL (fail) or call
malloc, depending on the state)
- William Hughes

Jul 25 '07 #32
On Jul 25, 4:41 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <1185352068.681434.313...@57g2000hsv.googlegroups. com>,

crox <craz...@gmail.comwrote:
it is really platform specific, for example in my system libc, malloc
has this implemetation:
...
/* why would you ever want a negative malloc, this would mean */
/* a very large positive number which can't be filled */
if ((int)nbytes < 0){

The argument to malloc() has type size_t, which is unsigned, so you
*can't* pass it a negative value. It may well be true that values
corresponding to negative ints are usually the result of a bug in the
program causing a negative value to be converted to a large size_t,
but I'm not sure why your code bothers to make this check, since if
requests for "very large" amounts of memory can't be filled, it will
fail anyway without the check.

I think the comment would be more accurate if it read "Why would you
ever want to malloc such a huge amount? It can't be done and is more
likely an erroneous attempt to malloc a negative size".
If the chip can address it, and if I have that much available, I would
be rather put out if the malloc() function arbitrarily decided not to
give it to me.
That little snippet of code is by a programmer trying to be more
clever than he ought to be.
IMO-YMMV.

Jul 25 '07 #33
REH
On Jul 17, 6:36 am, "niranjan.si...@gmail.com"
<niranjan.si...@gmail.comwrote:
This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....
regards
If you just wish to test your error paths, you don't really need to
make malloc fail, just make your program think that it did:

#if TESTING

/* function to determine if malloc should fail */
int malloc_should_fail(void);

#define malloc(S) (malloc_should_fail() ? NULL : (malloc)(S))

#endif

I don't believe it is portable to override malloc with a macro, but
its only for testing purposes, not your release builds.

Jul 25 '07 #34
In article <11**********************@o61g2000hsh.googlegroups .com>,
user923005 <dc*****@connx.comwrote:
>/* why would you ever want a negative malloc, this would mean */
/* a very large positive number which can't be filled */
>If the chip can address it, and if I have that much available, I would
be rather put out if the malloc() function arbitrarily decided not to
give it to me.
I assume from the comment that it isn't available. It's not unusual
for half the address space to be used for kernel memory. Of course,
if size_t is 64 bits, there's no prospect of more than half of it being
available anyway in the foreseeable future.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jul 25 '07 #35

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

25 posts views Thread by H.A. Sujith | last post: by
27 posts views Thread by Chess Saurus | last post: by
54 posts views Thread by Neo | last post: by
14 posts views Thread by Marlene Stebbins | last post: by
42 posts views Thread by Martin J鷨gensen | last post: by
40 posts views Thread by ramu | last post: by
71 posts views Thread by desktop | last post: by
173 posts views Thread by Marty James | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.