🚀 go-pugleaf

> *** malloc[278]: Deallocation of a pointer not malloced: 0xffffffff;
> This could be a double free(), or free() called with the middle of an
> allocated block; Try setting environment variable MallocHelp to see
> tools to help debug

I've seen this a lot, but not on 10.1.x. I'm using 10.0.4 and I see this 
whenever I try to free() a piece of memory that I've malloc()ed.

What I would do would be something like:

int *ptr1, *ptr2;

ptr1 = (char *)malloc( 100 * sizeof( int ) );
ptr2 = (char *)malloc( 200 * sizeof( int ) );

Now this would work alright until I freed one and tried to access the 
other as in:

free( ptr1 );
ptr2[1] = 10;     // your error appears at this point

This drove me crazy for a while and so I tried C++ new and delete and 
that worked without problem, and I could allocate and dealloc memory at 
will.

I looked into this some more just recently and I've noticed that this 
malloc problem goes away if you type cast when passing to free. I can't 
remember too well how it went but whenever you free()ed memory you 
needed to typecast in the following way:

free( (void *)ptr1 );
ptr2[123] = 11;   // this now works

I can't remember the cast exactly (it might be (char *) now that I think 
of it) but the fix to a bug that reports this error can be done in this 
way.

Weird that this bug is still in 10.1.x. I thought only oldies like 
myself had to suffer this.

Don't know if that helps,

Andrew

On Mon, 27 May 2002, No Body wrote:

> > *** malloc[278]: Deallocation of a pointer not malloced: 0xffffffff;
> > This could be a double free(), or free() called with the middle of an
> > allocated block; Try setting environment variable MallocHelp to see
> > tools to help debug
>
> I've seen this a lot, but not on 10.1.x. I'm using 10.0.4 and I see this
> whenever I try to free() a piece of memory that I've malloc()ed.

Right. This particular bug report happened because somebody tried to free
a memory block at -1. One might imagine they had a NULL pointer ( value is
0) and they subtracted 1 from it, it then failed the NULL check and some
code tried to free it. This is a Quicktime bug probably.  You will get
malloc errors of this kind whenever someone abuses the heap. The good news
is that on OS 9 these things would have eventually brought down the entire
machine. These days, the problem is logged as it happens and at worst it
will only bring down the app that is misbehaving.

When you run into a problem like this with Apple software, if you are
determined to make sure this is fixed, the correct thing to do is to log
on to Apple's bug reporter and provide a very complete bug report. Do not
try to filter, distort or interpret any of the information yourself. You
will only make it harder to fix the bug. Merely be the engineer's eyes and
ears. Report everything that happened. Attach the log file and any other
errors you see. Add any additional information you can think of relevant
to what might have changed at about the time that the problem started to
appear. For example if you recently upgraded to a new version of
Quicktime, you should include that information. If the problem started
only after registering Quicktime, that is important. If it only happens
with certain files but not others, that is important. There are millions
of other things that might have changed, not just these three, that might
be important. Your burden is to remember what happened just before you
started seeing this problem and report that, even if it is somewhat
embarrassing. The important thing is to fix the bug. We all do stupid user
tricks sometimes. The point is to be accurate and complete enough so that
the engineer can make the bug happen on his own machine. Once he can do
that, he can fix it. What would you need to know to make the problem
happen? Here is the link to the bug reporter:

	http://bugreporter.apple.com

If you are not a software developer, you will need to sign up as one. The
online membership is free:

	http://connect.apple.com

You do not need to actually develop any software to sign up and report a
bug. This formality is required so that you sign a NDA -- this allows
Apple to discuss the bug with you in private without worrying that you
will go make a capital case of it all over the internet. Users are
frequently so delighted that they are talking to someone at Apple that
they are tempted to proverbially yell it from the rooftops and may want to
post a transcript of the entire thing all over the internet for anyone to
see. Dont doooo that! It makes it impossible for Apple to actually discuss
bugs with you. The NDA makes sure that you will use the experience to
constructively address the bug in question.  Joining ADC also makes sure
Apple can get a hold of you if further information is required or they
want you to verify that it has been fixed.

Please note that it is VERY likely that any such bug fix will only appear
in new operating system releases. Do not expect that Apple will release a
backwards compatable patch for older operating systems, except perhaps as
part of the normal update process through software updater.

Ian
---------------------------------------------------
   Ian Ollmann, Ph.D.       iano@cco.caltech.edu
---------------------------------------------------