Re: How to safely remove an IOProc
Re: How to safely remove an IOProc
- Subject: Re: How to safely remove an IOProc
- From: "Paul Sanders" <email@hidden>
- Date: Mon, 8 Feb 2010 18:23:37 -0000
OK, thank you. And yes, every callback should carry a 'context'
pointer. Shame I missed that technote, but switching across to
the new API's should not be hard.
Do please consider updating the documentation. It is a
quagmire. This job took far longer because of it.
Regards,
Paul Sanders.
----- Original Message -----
From: "Jeff Moore" <email@hidden>
To: "CoreAudio API" <email@hidden>
Sent: Monday, February 08, 2010 5:41 PM
Subject: Re: How to safely remove an IOProc
On Feb 8, 2010, at 2:39 AM, Paul Sanders wrote:
> My IOProc calls a virtual function. If it gets called after I
> believe I have shut the device down, the object will have been
> deallocated, although you would think that my 'dispatcher'
> would
> show up in the stack trace. But how could a memory corruption
> bug affect the code, which is in a read-only segment? I am
> not
> using any other relevant API's (to my knowledge), but in any
> case, they would surely be registering their own IOProc's.
> Why
> would any of that result in mine being called?
Pretty much every single crash I have seen like yours over the
years has been due to deallocating the destination of the jump
too early. This typically happens when developers use a jump
island (like CATink in our SDK) to allow the same function to be
registered multiple times as an IOProc. They then deallocate
that jump island too early. This leaves a little nub on the
stack without a symbol jumping to a bad location, just like we
see here.
Short of that, you say you are calling a virtual method. The
same thing can happen that way if you deallocate the object that
implements the virtual method too early.
BTW, AudioDeviceCreateIOProcID/AudioDeviceDestroyIOProcID, which
supersede the deprecated
AudioDeviceAddIOProc/AudioDeviceRemoveIOProc, were created
specifically so that you don't have to use the jump island
pattern any longer.
Also, the AudioObject-based APIs in the HAL were added in Tiger.
The APIs they replace were not deprecated until Leopard. So
moving to them will not affect backward compatibility.
On Feb 8, 2010, at 5:32 AM, Paul Sanders wrote:
> Thanks Phillipe, that's a big help.
>
> Jeff, is there any likelihood that the old API's will go away?
> My code is fine, apart from this shutdown issue, and I am
> loathe
> to change something that works and is tested.
Deprecating an API should always be viewed as the first warning
that an API is going to be removed. Even if the API doesn't get
removed right away, deprecation usually means that the
implementation will be frozen and that bug fixing will get rarer
and rarer. So, it behooves you to head these warnings and move
on.
> Thanks - Paul Sanders.
>
> ----- Original Message -----
> From: "philippe wicker" <email@hidden>
> To: "Paul Sanders" <email@hidden>
> Cc: "CoreAudio" <email@hidden>
> Sent: Monday, February 08, 2010 10:46 AM
> Subject: Re: How to safely remove an IOProc
>
>>> Finally, you should consider migrating your code away from
>>> deprecated APIs like AudioDeviceGetProperty() and
>>> AudioDeviceRemoveIOProc.
>>
>>
>> To what? The Core Audio documentation is quite awful,
>> frankly.
>
> I think this is inside this tech note:
>
> http://developer.apple.com/mac/library/technotes/tn2010/tn2223.html
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list
> (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden