Unable to free malloc'd ptr

D

Default User

Jason said:
First of all, I need to apolgoize; I am not a programmer and its been
years since I last programmed something so this is probably a very
simple question.

For future questions you may have, post a complete, minimal, program
that demonstrates the problem.

That statement contains three conditions:

1. Complete - A program that can be cut and pasted into our compilers
if we choose, but at the very least we know is not missing anything.

2. Minimal - The program is reduced down as much as possible. That
means removing parts where you can to simplify it, but where it still
produces the failing behavior. Often the process will reveal the
section with the bug, but at least you will make the review process
easier.

3. Demonstrates the problem - The code you give us should be able to
produce the exact condition you are experiencing. In addition, you need
to tell us what the program was supposed to do, and what it did
instead. If it is failing to compile, transcribe exactly or
(preferably) cut and paste the compiler messages.




Brian
 
J

Jason Pawloski

No, that is completely wrong.

'I'm not a programmer', yet you are not prepared to believe what
experienced programmers tell you. You're out of your depth. Why ask here
if you've already made up your mind what the problem is?

'Damage after normal block means exactly what it says'. You've allocated
a 'normal' block of memory and then you've written past the end (i.e.
damaged it). Andre is right.

john

Hi John.

I'm sorry you weren't smart enough to understand what was going on.
Its BECAUSE I am not a programmer that I do not understand their
explanations and how it fits with my problem. I asked a question, they
responded, and now I understand (and, coincidentally, they were dead
on).

So I had a bunch of nice, polite, patient people help me with my
problem. Then there's you, a braying jackass who projects his own
arrogance onto others.

John, do you work in IT? I rarely deal with people from IT because
most of them, unfortunately, have your personality. Keep in mind your
arrogance and sarcasm the next time you get laid off or looked over
for a promotion. I get the impression that that happens a lot; I'd
imagine your coworkers don't like having you around either.
 
J

Jason Pawloski

Jason Pawloski wrote:
Relevant:
I have a local integer pointer:
int *nr1 = NULL;
within this function, I call another function
int *function2([parameters])
This function mallocs an int *ptr and returns it. So I use the
function like:
nr1 = function2([parameter]);
Now when I try to free it later in my first function (the one that
calls function2), I get an MSVC++ error. The exact wording is:
Debug Error!
Program: <path>
DAMAGE: after Normal block (#46) at 0x00431D80
Any suggestions on what might cause this? thanks!
Can you post function2?
--
Ian Collins.- Hide quoted text -
- Show quoted text -
Sure. Again, not a programmer by trade, etc.:
NB size is the absolute length of *list (ie number of elements), while
position is the INDEX of what to remove from the list. Confusingly
stupid, I know, but working it this way makes other things in the
program not relevant to this simple.
int *dropreel(int *list,int size,int position)
{
int *nl = NULL;
/*Put the index in range */
while(position > size-1) position = position - size;
while(position < 0) position = position + size;
nl = malloc(sizeof(int)*(size-1));
if(nl == NULL)
printf("WARNING!! NO MEMORY!\n");
memset(nl,0,sizeof(int)*(size-1));
if(position != size-1)
nl[0] = list[size-1];
else
nl[0] = list[size-2];
memcpy(&nl[1],list,sizeof(int)*(position));
memcpy(&nl[position+1],&list[(position+1)],sizeof(int)*(size-
position-1));
return nl;
}
It's a little confusing code, but it seems that your list[0] stores the
size
of the list, with list[1] starting the actual data. Does the size parm
being passed in include one for list[0] ? That is, are you simply
passing
size as list[0] into the function?
And if so, why are you decrementing size in the malloc? For example, if
you
had a list of three values:
list[0] = 3;
list[1] = 1;
list[2] = 2;
list[3] = 3;
you would be passing in size as 3, although it actually contains 4 ints.
Now, say you are wanting to remove element number 2. So you would pass
list, list[0], 2
correct?
Now, when you malloc, sizeof(int) * (size - 1)
size is 3. 3-1 = 2. You are only allocating 2 ints, when you acutally
need
3.
This is obvoiusly C code and not C++ (the giveaway is malloc's return
value
not being cast which is required in C++) otherewise I'd say just use
std::vector and be done with it.
Your while code is somewhat flakey (while (position > size - 1, etc...)
and
if it was me, if position was > size I'd print an error and return null.
It sounds most likely like you are not allocating enough memory and
overflowing the array with your memcpys.
Well, when I comment out the free, it doesn't crash, when I uncomment
it out, it does crash, so for whatever reason the free is the culprit.
Now if I'm underallocating my memory, and I write too much, that would
throw an error right then, and not at free, right?
I don't think vector class would be all that much simpler, because I
need the last element of the list to be dragged up to the top of the
list.
Since its just a free, normally I'd just leave the memory allocated
and be done with it, since I'm not publishing this software or
anything. But I'm required to do 100,000,000 iterations of this
simulation, and as you imagine 50 extra bytes here and there will
eventually kill you!

Easy enough to test. malloc with size * 2 and run it and see if it crashes.
If it still crashes, then it's probably not an overflow problem. If it
doesn't crash anymore, then you'll need to take a closer look at the size
your'e mallocing.

Incidently, you should use C++ and vectors and not have this problem.

I had an hour or two to play around with this today. mallocing the
size * 2 fixes the problem, although I'm getting something else now. I
would have never guessed that writing to adjacent blocks could cause
this problem.

All of you guys who helped and offered advice, I really appreciate
taking the time to help me with my program. Like I said, I'd be
looking at this code for a very long time without you guys.

Thanks again.
 
J

Jason Pawloski

Jason Pawloski said:
[snip]
It sounds most likely like you are not allocating enough memory and
overflowing the array with your memcpys.
Well, when I comment out the free, it doesn't crash, when I uncomment
it out, it does crash, so for whatever reason the free is the culprit.

Bad conclusion. You may have scrambled your memory long before you call
free.
Now if I'm underallocating my memory, and I write too much, that would
throw an error right then, and not at free, right?

Nope. That's what's called Undefined Behviour. At some point (I'm
currently guessing after function2 has returned, but before the free),
you've written past the array (or before it), or some other bad pointer
stuff and Undefined Behaviour happens. In your case, it sits there
quietly until free is called, then it blows up.
I don't think vector class would be all that much simpler, because I
need the last element of the list to be dragged up to the top of the
list.

Kinda an odd list... but it's your design.
Since its just a free, normally I'd just leave the memory allocated
and be done with it, since I'm not publishing this software or
anything. But I'm required to do 100,000,000 iterations of this
simulation, and as you imagine 50 extra bytes here and there will
eventually kill you!

A few more things:

1) you're never storing a pointer into this anywhere, only indexes, yes?

Thanks again for your help. I successfully debugged it today.

Yes that is correct.
2) All of this malloc/free 100,000,000 times is gonna be slow (and result
in memory fragmentation... details of which are somewhat off-topic). Are
we really in C++ or are you only doing C? Perhaps you would do better to
wrap this up in a class, and have a vector or deque as your data member.
Write shim methods that pass through all of your accesses, and add your
object moving logic in the erase() method.

Its essentially done now, I just have to hand test some special cases
and run it. So I'm not too motivated to rewrite it! Speed is not a
concern; if it finishes in fewer than 5 days, I'm okay. Otherwise I'll
do fewer iterations and see if the volatility is small.

Thanks again.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,292
Messages
2,571,494
Members
48,180
Latest member
DelmarCarv

Latest Threads

Top