Strange thing about malloc()

[Ronny Mandal]

Hi!

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Is it just a Win32-issue, or a bug?

--

Regards,

Ronny Mandal


This e-mail and any attachment are confidential and may be privileged or
otherwise protected from disclosure. It is solely intended for the person(s)
named above. If you are not the intended recipient, any reading, use,
disclosure, copying or distribution of all or parts of this e-mail or
associated attachments is strictly prohibited. If you are not an intended
recipient, please notify the sender immediately by replying to this message
or by telephone and delete this e-mail and any attachments permanently from
your system.

 

[Gordon Burditt]

This e-mail and any attachment are confidential and may be privileged or

otherwise protected from disclosure. It is solely intended for the person(s)
named above. If you are not the intended recipient, any reading, use,
disclosure, copying or distribution of all or parts of this e-mail or
associated attachments is strictly prohibited. If you are not an intended
recipient, please notify the sender immediately by replying to this message
or by telephone and delete this e-mail and any attachments permanently from
your system.

It's absolutely ridiculous to put this on a worldwide USENET posting.
Don't threaten people you want to help you.

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Describe how you can tell the difference between "works" and "doesn't work".
Some code would be nice.

I suspect that you are running over the end of the array, and that
you can get away with it with an odd number (possibly because malloc()
rounds up the size), but not with an even number (when it might not
round up). But there's no way to tell without code.

Gordon L. Burditt

 

[Emmanuel Delahaye]

Ronny Mandal wrote on 19/04/05 :

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Is it just a Win32-issue, or a bug?

Hard to say. What do you meant by "it will not work." ? Post a
compilable snippet that exposes the problem with a description of the
environment (required inputs, expected outputs...)

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Eric Sosman]

Hi!

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Is it just a Win32-issue, or a bug?

The latter. My crystal ball tells me your error
is on line 42.

"Doctor, it hurts!"

"What hurts?"

"What do you think you're doing, snooping in my
personal affairs?"

 

[Ronny Mandal]

It's absolutely ridiculous to put this on a worldwide USENET posting.

No it is not. I've noticed stranger things about c-releases, e.g in
non-stable releases that is almost like "doesn't work when the moon is
full", which other people from the USENET have had issues with. And then,
because of the USENET, the inquirer receives help.

Don't threaten people you want to help you.


Describe how you can tell the difference between "works" and "doesn't
work".
Some code would be nice.

Well, in general people on USENET is not interested in posted code. But
after trying to isolate the problem into a few lines of code, it still
behaves strange.

I suspect that you are running over the end of the array, and that
you can get away with it with an odd number (possibly because malloc()
rounds up the size), but not with an even number (when it might not
round up). But there's no way to tell without code.

This seems like a plausible answer, regarding the "you can get away with it
with an odd number". I've never read anyplace about how malloc works
"internally", but maybe it is written in the FAQ. But since the FAQ is
really extensive, I sometimes ask people from ther USENET.

 

[Artie Gold]

It's absolutely ridiculous to put this on a worldwide USENET posting.
Don't threaten people you want to help you.

That part of the sig is likely put there by the server through which the
message was posted. It's probably not the OP's fault.

--ag

 

[Artie Gold]

No it is not. I've noticed stranger things about c-releases, e.g in
non-stable releases that is almost like "doesn't work when the moon is
full", which other people from the USENET have had issues with. And then,
because of the USENET, the inquirer receives help.

He was referring to the stuff at the botom of your sig.

Well, in general people on USENET is not interested in posted code. But
after trying to isolate the problem into a few lines of code, it still
behaves strange.

Not true. Best is to post the *minimal* compilable code that exhibits
the behavior that made you post in the first place.

This seems like a plausible answer, regarding the "you can get away with it
with an odd number". I've never read anyplace about how malloc works
"internally", but maybe it is written in the FAQ. But since the FAQ is
really extensive, I sometimes ask people from ther USENET.

Understood. When it comes to malloc(), however, its internal workings
should be generally transparent. As has been mentioned above, an overrun
in some other piece of dynamically allocated memory is likely the culprit.

HTH,
--ag

 

[Jonathan Bartlett]

If you're interested in the workings of malloc(), you should check out this:

http://www.ibm.com/developerworks/linux/library/l-memory/

Jon

 

[Keith Thompson]

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Is it just a Win32-issue, or a bug?

You have a typo on line 372 of main.c.

I'm only guessing, but that's all I can do with the information you've
provided. What is your program attempting to do? How exactly does it
not work?

Can you post a small complete program that exhibits the problem?

(If it's a Win32 issue, we can't help you here.)

This e-mail and any attachment are confidential and may be privileged or
otherwise protected from disclosure.

[snip]

It's not an e-mail, it's a Usenet posting. I suggest you drop the
meaningless disclaimer.

 

[Richard Tobin]

That part of the sig is likely put there by the server through which the
message was posted. It's probably not the OP's fault.

Quite so, but if we don't complain to people who use such servers, how
are they ever going to be replaced?

If, by choice, you use a server that adds this sort of thing to your
message, it makes you look silly. If you work for a company that puts
it on all your outgoing messages, it makes your company look as if
they don't understand the net, and are probably the sort who spend
more money on lawyers than products.

-- Richard

 

[Flash Gordon]

Hi!

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Is it just a Win32-issue, or a bug?

There is almost certainly a bug somewhere in *your* code, my guess would
be overrunning the buffer you have created. Reduce your program to the
smallest compilable example that exhibits the problem and does not use
extensions and post it here and you might get some help.

 

[Ronny Mandal]

Sorry about the footer, sometimes I forget to remove it, it comes
automatically, but not on my personal behalf.

Indeed, it is not my typing.

 

[Keith Thompson]

If you're interested in the workings of malloc(), you should check out this:

http://www.ibm.com/developerworks/linux/library/l-memory/

Correction: If you're interested in the workings of some
system-specific implementations of malloc().

 

[Christian Bau]

Hi!

I am writing a program that'll read binary integers from a file, put them
into a dynamic array. THe array is first declared

int* a = malloc( sizeof( int ) * N ) <-- N is the number of slots.

When N is odd, the program will work just fine, however when N is even, it
will not work.

Is it just a Win32-issue, or a bug?

Have a good look at your code. Are you by any chance writing to a [N] ?
Assuming that malloc () was successful, you are allowed to write to a
[0] up to a [N-1], but not a [N].

 

[Richard Bos]

Quite so, but if we don't complain to people who use such servers, how
are they ever going to be replaced?

If, by choice, you use a server that adds this sort of thing to your
message, it makes you look silly. If you work for a company that puts
it on all your outgoing messages, it makes your company look as if
they don't understand the net, and are probably the sort who spend
more money on lawyers than products.

IOW, like Microsoft ;-)

Richard

 

[Ronny Mandal]

Thanks for helping me out, strange thing that I just *forgot* that a[N]
holds N-1 elements. malloc worked just fine from the beginning.

Ronny Mandal

 

[Alan Balmer]

Thanks for helping me out, strange thing that I just *forgot* that a[N]
holds N-1 elements. malloc worked just fine from the beginning.

Um, not exactly. When you have
int* a = malloc( sizeof( int ) * N ) ;

a can hold N elements, but the first one is a[0] and the last one is
a[N-1].

Probably what you meant.