Re: How to safely remove an IOProc
Re: How to safely remove an IOProc
- Subject: Re: How to safely remove an IOProc
- From: Jeff Moore <email@hidden>
- Date: Mon, 08 Feb 2010 09:41:54 -0800
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