Re: Mysterious crash in HALObject::PropertiesChanged
Re: Mysterious crash in HALObject::PropertiesChanged
- Subject: Re: Mysterious crash in HALObject::PropertiesChanged
- From: Jeff Moore <email@hidden>
- Date: Sat, 06 Mar 2010 15:58:11 -0800
On Mar 6, 2010, at 3:52 PM, Paul Sanders wrote:
> Hi Jeff,
>
> Thanks for this. I had surmised as much myself. I'm as sure as one ever can be that our listeners are coming and going when they should, and in this case they would still be installed anyway as the device was still in use by us. My besttheory is that the Audio Hijack Server plugin (whatever that might be) has installed a listener proc of its own and failed to remove it properly. This crash is very much a one-off. How many of our other uses have Audio Hijack installed I have no idea. If I learn more, I'll post back. Have you any idea what Instant Hijack Server actually does?
Audio Hijack is a tool that lets you snarf the audio of an app. I think that they have a few techniques they use to do this. The Instant Hijack Server is no doubt a part of one of those.
> I worked around my problems with the Hear plugin by the way, if you remember that. I chased JoeSoft to look into it and when they did it turned out that if you install the same IOProc for two different devices (which we were doing, we have one central routine which acts as a demultiplexer), they drop the ball. I now use an IOProc 'shim' (which just calls my demux routine) for each device in use and that fixes the crashes. They tell me they are going to fix this.
I'm glad that you were able to sort this out.
--
Jeff Moore
Core Audio
Apple
> Paul Sanders
>
> ----- Original Message -----
> From: "Jeff Moore" <email@hidden>
> To: "CoreAudio API" <email@hidden>
> Sent: Saturday, March 06, 2010 11:28 PM
> Subject: Re: Mysterious crash in HALObject::PropertiesChanged
>
> Crashes like this usually mean that the destination of the call out from the HAL to the ListenerProc is a bad address.
>
> ...
> Audio Hijack has been known to patch the HAL to do what it does. I don't know if that is the case here, but having the user disable Audio Hijack can't hurt.
>
> ...
>
> If your code is making use of jump trampolines (aka CATink from our SDK), it is possible that you are hitting this because the jump island is being deallocated early. If you aren't using jump trampolines or you are really really sure about your usage of them, then there is the possibility of memory corruption.
>
> If I was debugging this, I'd start by examining my listener procs and how I go about adding and removing them.
_______________________________________________
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