N
niranjan.singh
This is regarding to test an SDK memory stuff.
In what situation malloc gets fail.
any comment/reply pls....
regards
In what situation malloc gets fail.
any comment/reply pls....
regards
S
santosh
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>
R
Richard Heathfield
santosh said:
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. :-(
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. :-(
S
santosh
Richard Heathfield wrote:
I apologise in advance if this post appears multiple times. Google has
been wretched to use today.
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.
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.
I apologise in advance if this post appears multiple times. Google has
been wretched to use today.
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.
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.
K
Keith Thompson
[email protected] said:
The C standard says that malloc can fail (and if so, it returns a null
pointer); it doesn't say under what circumstnaces it can fail.
Realistically, it should fail if there isn't enough memory available
for the requested allocation; you could either run out of memory on
the system, or use up the memory allocated to your program (or
process, or whatever).
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.
There are two problems with this approach.
First, if you're on a multi-user or multi-processing system, doing so
could interfere with other users and/or other processes.
Second, on some systems (I think Linux is an example), malloc doesn't
actually indicate failure if it can't allocate the requested memory.
Instead, it allocates a range of addresses to your program without
actually allocating the memory. The memory is only allocated when you
attempt to access it. At that point, it's too late to indicate a
simple allocation failure, and the OS responds by killing processes.
This behavior is arguably non-conforming.
H
Harald van =?UTF-8?B?RMSzaw==?=
Keith said:
Disclaimer: I'm assuming the behaviour you described violates the standard.
Linux by default behaves that way, but it can be configured to behave in a
conforming manner. I know conforming implementations are allowed to have
non-conforming modes so long as at least one mode conforms to the standard,
but I'm curious, would they be required to clearly document to appropriate
sysctl?
R
Richard Heathfield
Keith Thompson said:
Fortunately, there is also at least one non-obvious way.
(And yes, it involves cheating, but *not* by resorting to non-portable
code.)
<snip>
Fortunately, there is also at least one non-obvious way.
(And yes, it involves cheating, but *not* by resorting to non-portable
code.)
<snip>
U
user923005
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 <Enter> key to release %u megs memory\n",
(unsigned) megs);
fgets(string, sizeof string, stdin);
free(waster);
}
return 0;
}
R
Richard Heathfield
user923005 said:
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).
I recommend strtoul(argv[1], NULL, 10) instead of atoi(argv[1]).
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).
I recommend strtoul(argv[1], NULL, 10) instead of atoi(argv[1]).
D
Daniel Rudy
At about the time of 7/17/2007 3:36 AM, (e-mail address removed) stated
the following:
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.
the following:
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.
D
Doug
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
R
Richard Heathfield
Doug said:
Well, it wasn't intended that way, but how you interpret it is your
affair, not mine.
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.
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?
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.
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.
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.
Well, it wasn't intended that way, but how you interpret it is your
affair, not mine.
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.
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?
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.
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.
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.
S
santosh
"]
At about the time of 7/17/2007 3:36 AM, (e-mail address removed)
stated the following:
something like this:
ptr = malloc(0xFFFFFFFF);
That will usually cause the allocation to fail...[/QUOTE]
Many modern workstations have 4 Gb or more of memory installed.
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.
At about the time of 7/17/2007 3:36 AM, (e-mail address removed)
stated the following:
something like this:
ptr = malloc(0xFFFFFFFF);
That will usually cause the allocation to fail...[/QUOTE]
Many modern workstations have 4 Gb or more of memory installed.
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.
?
=?ISO-8859-1?Q?Bernhard_M=FCller?=
santosh said:
Many modern workstations have 4 Gb or more of memory installed.
[/QUOTE]
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
F
Flash Gordon
Bernhard Müller wrote, On 22/07/07 20:24:
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.
Actually, it *is* guaranteed to be unsigned. This is why you have
SIZE_MAX but not SIZE_MIN.
H
Harald van =?UTF-8?B?RMSzaw==?=
Flash said:
It is guaranteed to be an unsigned integer type, which might or might not be
the type specified by "unsigned" (aka "unsigned int").
F
Flash Gordon
Harald van Dijk wrote, On 22/07/07 21:08:
I meant an unsigned type, not unsigned int. I should have been clear.
I meant an unsigned type, not unsigned int. I should have been clear.
H
Harald van =?UTF-8?B?RMSzaw==?=
Flash said:
I know that's what you meant. I meant that it doesn't necessarily contradict
Bernhard Müller's claim.
A
Army1987
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.
A
Army1987
I think it also depends on the size of the blocks.
For example on my system (Ubuntu 6.10 with 1GB RAM and 1GB swap
partition)
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
unsigned long i;
size_t size = 2000000000;
for (i = 0; malloc(size); i++)
continue;
printf("%.7g kilobytes\n", i * (size / 1024.0));
return 0;
}
prints 0 if size is very large, about 3 GB if it is between
approx. 10000 and 1000000, and gets eventually killed if it is
very small.