Strange malloc problem

[Me]

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));

<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a size
around 2KB everything works ok. When I read a file with a size of around
1.5MB malloc doesn't allocate the memory. I'm using lcc-win32 as the
compiler. The program in a running state is using around 7MB in memory
before malloc.

Hope anyone can help.

[Vladimir Oka]

Me wrote:

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));
Using `sizeof *lcdata` may be better (easier to maintain).
<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a size
around 2KB everything works ok. When I read a file with a size of around
1.5MB malloc doesn't allocate the memory. I'm using lcc-win32 as the
compiler. The program in a running state is using around 7MB in memory
before malloc.

Have you considered the possibility that you've run out of memory? What
does "does not allocate the memory mean"? Does it return NULL? You
don't seem to test for that. There may be OS/compiler specific ways of
checking how much memory you have left.

PS
Do you /really/ have to read /all/ of a 1.5MB file into memory at once?

[pemo]

Me wrote:

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));

<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a
size around 2KB everything works ok. When I read a file with a size
of around
1.5MB malloc doesn't allocate the memory. I'm using lcc-win32 as the
compiler. The program in a running state is using around 7MB in memory
before malloc.

Hope anyone can help.

What's fsize's *type* - unlikely it's overflowing, but worth knowing.
--
==============
Not a pedant
==============

[Me]

"Vladimir Oka" <no****@btopenw orld.com> wrote in
news:11******** **************@ i40g2000cwc.goo glegroups.com:

Me wrote:

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));
Using `sizeof *lcdata` may be better (easier to maintain).

<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a
size around 2KB everything works ok. When I read a file with a size
of around 1.5MB malloc doesn't allocate the memory. I'm using
lcc-win32 as the compiler. The program in a running state is using
around 7MB in memory before malloc.

Have you considered the possibility that you've run out of memory?
What does "does not allocate the memory mean"? Does it return NULL?
You don't seem to test for that. There may be OS/compiler specific
ways of checking how much memory you have left.

I made a check for that:

if (!*lcdata)
{
<allocate error message>
return 0;
}

PS
Do you /really/ have to read /all/ of a 1.5MB file into memory at
once?

Well it would be possible to read smaller parts, but that would make the
program very complex. I also have to mention that this malloc is inside a
function (1MB stack ?) Can't imagine it has anything to do with the stack
because declaration, malloc and free is all inside the function.

[Me]

"pemo" <us***********@ gmail.com> wrote in news:e7******** **@news.ox.ac.u k:

Me wrote:

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));

<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a
size around 2KB everything works ok. When I read a file with a size
of around
1.5MB malloc doesn't allocate the memory. I'm using lcc-win32 as the
compiler. The program in a running state is using around 7MB in memory
before malloc.

Hope anyone can help.

What's fsize's *type* - unlikely it's overflowing, but worth knowing.

fsize is of type long and the actual test value for fsize is 1612288.

[Chris Dollin]

Me wrote:

"Vladimir Oka" <no****@btopenw orld.com> wrote in
news:11******** **************@ i40g2000cwc.goo glegroups.com:

Have you considered the possibility that you've run out of memory?
What does "does not allocate the memory mean"? Does it return NULL?
You don't seem to test for that. There may be OS/compiler specific
ways of checking how much memory you have left.

I made a check for that:

if (!*lcdata)

Did you /really/ write `!*lcdata`? Not `!lcdata` (I prefer `lcdata == 0`)?

If malloc returns null, lcdata is null, and *lcdata is undefined, BOOM.

PS
Do you /really/ have to read /all/ of a 1.5MB file into memory at
once?

Well it would be possible to read smaller parts, but that would make the
program very complex.

Would it? Are you sure? It depends on the problem.
I also have to mention that this malloc is inside a
function (1MB stack ?) Can't imagine it has anything to do with the stack
because declaration, malloc and free is all inside the function.

It will depend, for example, on how much store programs are allowed
to allocate. You don't necessarily get everything that's available.

--
Chris "pseudo-Ivanova" Dollin
"No-one here is exactly what he appears." G'kar, /Babylon 5/

[Vladimir Oka]

Me wrote:

"Vladimir Oka" <no****@btopenw orld.com> wrote in
news:11******** **************@ i40g2000cwc.goo glegroups.com:

Me wrote:

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));
Using `sizeof *lcdata` may be better (easier to maintain).

<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a
size around 2KB everything works ok. When I read a file with a size
of around 1.5MB malloc doesn't allocate the memory. I'm using
lcc-win32 as the compiler. The program in a running state is using
around 7MB in memory before malloc.

Have you considered the possibility that you've run out of memory?
What does "does not allocate the memory mean"? Does it return NULL?
You don't seem to test for that. There may be OS/compiler specific
ways of checking how much memory you have left.

I made a check for that:

if (!*lcdata)

ITYM

if (!lcdata)

If not, you may find that where `lcdata` points to in case of a large
file (by coincidence) is a NULL pointer!
{
<allocate error message>
return 0;
Returning 0 usually means success. To be sure, return EXIT_FAILURE.
}

PS
Do you /really/ have to read /all/ of a 1.5MB file into memory at
once?

Well it would be possible to read smaller parts, but that would make the
program very complex.

Maybe, but it would certainly be easier on resources, and friendlier in
multi-tasking environments. However, only you can be the judge of where
the best line of compromise lies (or is it your users?).
I also have to mention that this malloc is inside a
function (1MB stack ?) Can't imagine it has anything to do with the stack
because declaration, malloc and free is all inside the function.

SHould be irrelevant. Memory allocated in a function is not local to
it. Memory allocation (using `malloc()`) comes out of a "global" memory
pool available to C program (details are implementation defined).

[Me]

Me <ju****@here.co m> wrote in
news:Xn******** *************** ****@194.109.13 3.242:

Hi,

I ran into a malloc problem but I can't find the solution.

I try to read a file into a variable with malloc like this:

BYTE *lcdata;

lcdata = malloc(fsize*si zeof(BYTE));

<do stuff>

free(lcdata);
lcdata = NULL;

fsize is the size of the file I'm reading. When I read a file with a
size around 2KB everything works ok. When I read a file with a size of
around 1.5MB malloc doesn't allocate the memory. I'm using lcc-win32
as the compiler. The program in a running state is using around 7MB in
memory before malloc.

Hope anyone can help.

Problem solved. It was the check that did it I now changed it to if
(lcdata==NULL)

Thanks for the help people !

[Quas.co.ua]

Chris Dollin wrote:

Me wrote:

"Vladimir Oka" <no****@btopenw orld.com> wrote in
news:11******** **************@ i40g2000cwc.goo glegroups.com:

Have you considered the possibility that you've run out of memory?
What does "does not allocate the memory mean"? Does it return NULL?
You don't seem to test for that. There may be OS/compiler specific
ways of checking how much memory you have left.

I made a check for that:

if (!*lcdata)

Did you /really/ write `!*lcdata`? Not `!lcdata` (I prefer `lcdata == 0`)?

If malloc returns null, lcdata is null, and *lcdata is undefined, BOOM.

I was also possible to do such

.....
unsigned char * lcdata;
.....
lcdata=(unsigne d char *)calloc(fsize, sizeof(unsigned char))
lcdata[0]=lcdata | lcdata >> 8 | lcdata >> 16 | lcdata >> 24;
if (*lcdata)
{
error_message;
exit(error_code );//because begine of the stack in main() is already corrupted
:)))
}
if you wanna see interpreter of strange language wellcom to
http://users.svitonline.com/quas/tec

Zis is ze let' tou censoers.
--by ManoNegra

PS
Do you /really/ have to read /all/ of a 1.5MB file into memory at
once?

Well it would be possible to read smaller parts, but that would make the
program very complex.

Would it? Are you sure? It depends on the problem.

I also have to mention that this malloc is inside a
function (1MB stack ?) Can't imagine it has anything to do with the stack
because declaration, malloc and free is all inside the function.

It will depend, for example, on how much store programs are allowed
to allocate. You don't necessarily get everything that's available.

--
Chris "pseudo-Ivanova" Dollin
"No-one here is exactly what he appears." G'kar, /Babylon 5/

[Peter Shaggy Haywood]

Groovy hepcat Quas.co.ua was jivin' on Tue, 20 Jun 2006 22:40:02 +0300
in comp.lang.c.
Re: Strange malloc problem's a cool scene! Dig it!

Chris Dollin wrote:

Me wrote:

> "Vladimir Oka" <no****@btopenw orld.com> wrote in
> news:11******** **************@ i40g2000cwc.goo glegroups.com:

>> Have you considered the possibility that you've run out of memory?
>> What does "does not allocate the memory mean"? Does it return NULL?
>> You don't seem to test for that. There may be OS/compiler specific
>> ways of checking how much memory you have left.
>
> I made a check for that:
>
> if (!*lcdata)

Did you /really/ write `!*lcdata`? Not `!lcdata` (I prefer `lcdata == 0`)?

If malloc returns null, lcdata is null, and *lcdata is undefined, BOOM.

I was also possible to do such

....
unsigned char * lcdata;
....
lcdata=(unsign ed char *)calloc(fsize, sizeof(unsigned char))
lcdata[0]=lcdata | lcdata >> 8 | lcdata >> 16 | lcdata >> 24;

But, since the allocation has failed and calloc() has returned a
null pointer, and you are therefore dereferencing a null pointer,
BLAMMO! The nasal demons take over your linen closet and demand that
you give them fabric softener, threatening to shred your sheets if you
don't.
if (*lcdata)
And just for bad measure, you reopen the door to Nasal Hell by
dereferencing a null pointer again, allowing the nasal demons to take
over your bathroom so they can point and laugh at you every time you
take a bath.
{
error_message;
And what is that, exactly; a macro expanding to something useful,
perhaps?
exit(error_code );//because begine of the stack in main() is already corrupted
:)))
}

if you wanna see interpreter of strange language wellcom to
http://users.svitonline.com/quas/tec

If it contains examples of the kind you've displayed above, I'm not
surprised it is for a strange language. That language is Ubish, no
doubt, the native tongue of the nasal demons.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technicall y correct" English; but since when was rock & roll "technicall y correct"?