Using MallocDebug on a component

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Darrin Cardani - 15 Dec 2004 17:23 GMT

I have a Mach-O QuickTime component built using CodeWarrior Pro 8.3 and
linked with the Mac OS X PowerPC Mach-O linker. Occasionally, I see an
error message in the console log that there was a double free when
using my component in QuickTime PlayerPro. I'd like to use MallocDebug
to figure out where it's coming from, but MallocDebug doesn't show me
the symbols from my component. It only shows the names of OS routines.
Is there any way to get it to show me the symbols from my component as
well?

Alternatively, I attempted to add libMallocDebug.a to my project, but
it can't link because it can't find the code for "eprintf". In reading
the archives of this newsgroup, I see I'm supposed to use the BSD
headers instead of the MSL ones. However, my attempts to switch my
project failed. Is there a tutorial on how to do that?

Thanks,
Darrin

Reply to this Message

Eric Albert - 15 Dec 2004 18:39 GMT

> I have a Mach-O QuickTime component built using CodeWarrior Pro 8.3 and
> linked with the Mac OS X PowerPC Mach-O linker. Occasionally, I see an
[quoted text clipped - 4 lines]
> Is there any way to get it to show me the symbols from my component as
> well?

I'm not sure, but if you can't get it to work, you should file a bug
report with Apple (and send me the bug number). MallocDebug should be
able to find symbols in components.

-Eric

Signature

Eric Albert ejalbert@cs.stanford.edu
http://outofcheese.org/

Reply to this Message

Darrin Cardani - 15 Dec 2004 20:52 GMT

> I'm not sure, but if you can't get it to work, you should file a bug
> report with Apple (and send me the bug number). MallocDebug should be
> able to find symbols in components.

I thought maybe it was because I was only exporting my component
dispatch routine. But I just added several other routine names to the
export list, and they aren't showing up, either. I'm baffled.

I'm also curious about something related I'm seeing. In addition to the
occasional extra free, on some runs with MallocDebug, I get several
thousand copies of this line:

MallocDebug: frame pointer goes from bffd7140 to bffe7b0 -- assuming
invalid.

The interesting thing is that IsHeapValid () still returns true after
this error shows up. I believe I have a lead on where this corruption
might be starting, but I'm curious what exactly the error message
means, and if there are any tools to help me narrow down the problem?

Thanks,
Darrin

Reply to this Message

Eric Albert - 16 Dec 2004 06:34 GMT

> > I'm not sure, but if you can't get it to work, you should file a bug
> > report with Apple (and send me the bug number). MallocDebug should be
[quoted text clipped - 3 lines]
> dispatch routine. But I just added several other routine names to the
> export list, and they aren't showing up, either. I'm baffled.

It's almost certainly a bug. Please file a bug report (and again, send
me the number).

> I'm also curious about something related I'm seeing. In addition to the
> occasional extra free, on some runs with MallocDebug, I get several
[quoted text clipped - 7 lines]
> might be starting, but I'm curious what exactly the error message
> means, and if there are any tools to help me narrow down the problem?

Considering that this is the implementation of IsHeapValid on 10.3.6,
I'm not surprised you're seeing it return true:

_IsHeapValid:
90305610 li r3,0x1
90305614 blr

(You can see this by running 'otool -tV
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.f
ramework/CarbonCore' and looking for "IsHeapValid:" in the output.)

I've filed a bug report to get IsHeapValid deprecated, but that doesn't
help you.

I'd suggest using Guard Malloc to track down the problem. It's much
better at catching memory smashers than MallocDebug is, though it also
causes your application to run as much as 100x slower.

Hope this helps,
Eric

Signature

Eric Albert ejalbert@cs.stanford.edu
http://outofcheese.org/

Reply to this Message

Miro Jurisic - 16 Dec 2004 06:51 GMT

> I'd suggest using Guard Malloc to track down the problem. It's much
> better at catching memory smashers than MallocDebug is, though it also
> causes your application to run as much as 100x slower.

Guard Malloc requires running with flat namespaces which makes it incompatible
with almost every app compiled by CW. (Specifically, if you use MSL, you can't
use flat namespaces.) You are not the only one who's very fond of this answer,
but it's not nearly as useful as it may seem.

hth

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

Alexey Proskuryakov - 16 Dec 2004 11:47 GMT

On 16.12.2004 09:51, in article
macdev-B4B3D0.01510916122004@senator-bedfellow.mit.edu, "Miro Jurisic"
<macdev@meeroh.org> wrote:

> Guard Malloc requires running with flat namespaces which makes it incompatible
> with almost every app compiled by CW. (Specifically, if you use MSL, you can't
> use flat namespaces.) You are not the only one who's very fond of this answer,
> but it's not nearly as useful as it may seem.

One more reason to keep using CFM in CodeWarrior ;)

- WBR, Alexey Proskuryakov

Reply to this Message

Eric Albert - 17 Dec 2004 06:02 GMT

> > I'd suggest using Guard Malloc to track down the problem. It's much
> > better at catching memory smashers than MallocDebug is, though it also
[quoted text clipped - 5 lines]
> who's very fond of this answer, but it's not nearly as useful as it
> may seem.

Well, it's extraordinarily useful for applications that can run with a
flat namespace. :) But yes, as I mentioned on xcode-users a week or two
ago, Apple's well aware of the need to use Guard Malloc and MallocDebug
on applications that can't run with a flat namespace.

-Eric

Signature

Eric Albert ejalbert@cs.stanford.edu
http://outofcheese.org/

Reply to this Message

Darrin Cardani - 16 Dec 2004 17:11 GMT

> It's almost certainly a bug. Please file a bug report (and again, send
> me the number).

Will do.

> > The interesting thing is that IsHeapValid () still returns true after
> > this error shows up. I believe I have a lead on where this corruption
[quoted text clipped - 7 lines]
> 90305610 li r3,0x1
> 90305614 blr

Oh brother! Well, at least now I know. Thanks.

> I'd suggest using Guard Malloc to track down the problem. It's much
> better at catching memory smashers than MallocDebug is, though it also
> causes your application to run as much as 100x slower.

To which Miro replied:

> Guard Malloc requires running with flat namespaces which makes it
> incompatible
> with almost every app compiled by CW. (Specifically, if you use MSL,
> you can't
> use flat namespaces.)

So is there any other option?

Thanks,
Darrin

Reply to this Message

Miro Jurisic - 16 Dec 2004 20:50 GMT

> > Guard Malloc requires running with flat namespaces which makes it
> > incompatible with almost every app compiled by CW. (Specifically, if you
> > use MSL, you can't use flat namespaces.)
>
> So is there any other option?

Yeah, see
<http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/i
ndex.html>, particularly the "Enabling Debugging Features" section.

hth

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

Darrin Cardani - 16 Dec 2004 23:41 GMT

> Yeah, see
>
> <http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemor
> y/i
> ndex.html>, particularly the "Enabling Debugging Features" section.

Oh, I thought those would have the same problem as directly linking
with libMallocDebug or using the MallocDebug application. OK.

Thanks,
Darrin

Reply to this Message

Miro Jurisic - 17 Dec 2004 01:08 GMT

> > Yeah, see
> >
[quoted text clipped - 3 lines]
> Oh, I thought those would have the same problem as directly linking with
> libMallocDebug or using the MallocDebug application. OK.

You should read <http://developer.apple.com/technotes/tn2004/tn2124.html>
because it's one of the most useful technotes ever. In particular:

"IMPORTANT: These environment variables do not require a special memory library
(like MallocDebug or the Guarded Memory Allocator). In fact, they are supported
by the default, non-debug memory allocator, and are, therefore, always
available."

hth

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

Brad Oliver - 20 Dec 2004 06:05 GMT

> Alternatively, I attempted to add libMallocDebug.a to my project, but
> it can't link because it can't find the code for "eprintf".

You can roll your own eprintf. I stole this from the gcc sources:

extern "C" void __eprintf (const char *string, const char *expression,
unsigned int line, const char *filename)
{
fprintf (stderr, string, expression, line, filename);
fflush (stderr);
abort ();
}

Signature

Brad Oliver
bradman@pobox.com.AM_SPAY

Reply to this Message

Mac Forum / Programming / CodeWarrior / December 2004

Using MallocDebug on a component