Re: compiler bug??
Re: compiler bug??
- Subject: Re: compiler bug??
- From: "Andy O'Meara" <email@hidden>
- Date: Thu, 08 Sep 2005 12:58:59 -0400
Indeed, something is fishy. Assuming your reply to Chris is the case, the
only other likely possibility is that there's some memory smashing going on.
Since everything seems to go to hell as a function of member placement, put
a char[ 128 ] as the first and last member of this class, zero them out on
construction, run your app for a while, and then break now and then and
verify they're both zero, etc.
Look on the bright side: if you are smashing memory, at least it seems to be
reproducible (vs. rare/erratic).
Good luck,
Andy
On 9/8/05 11:24 AM, "Philip Lukidis" <email@hidden> wrote:
> Here is the code which fails (please keep in mind that the member
> mFireLogPublisher was not used):
>
> #ifdef FIRELOGCORE
> class IOFireLogPublisher;
> #endif
> class HerculesAudioEngine : public IOAudioEngine
> {
> OSDeclareDefaultStructors(HerculesAudioEngine)
>
> public:
> #ifdef FIRELOGCORE
> IOFireLogPublisher *mFireLogPublisher;
> #endif
>
> This works:
>
> #ifdef FIRELOGCORE
> class IOFireLogPublisher;
> #endif
> class HerculesAudioEngine : public IOAudioEngine
> {
> OSDeclareDefaultStructors(HerculesAudioEngine)
>
> public:
> #ifdef FIRELOGCORE
> IOFireLogPublisher *mFireLogPublisher;
> #else
> void *mFireLogPublisher;
> #endif
>
> This works too:
>
> #ifdef FIRELOGCORE
> class IOFireLogPublisher;
> #endif
> class HerculesAudioEngine : public IOAudioEngine
> {
> OSDeclareDefaultStructors(HerculesAudioEngine)
>
> public:
> // MANY other members
> #ifdef FIRELOGCORE
> IOFireLogPublisher *mFireLogPublisher;
> #endif
>
> If you have any insight, please share.
>
> thanks,
>
> Philip Lukidis
>
> -----Original Message-----
> From: Andy O'Meara [mailto:email@hidden]
> Sent: Thursday, September 08, 2005 10:02 AM
> To: Philip Lukidis
> Subject: Re: compiler bug??
>
>
>
> Can you please include more of your class (since the problem seems like it
> may be contextual). IOW, please include the snippets of what does work and
> doesn't work in context.
>
> Andy
>
>
>
>
> On 9/8/05 9:50 AM, "Philip Lukidis" <email@hidden> wrote:
>
>> Apologies. Audio ceased to work (this is a 1394 audio device), and I saw
>> evidence of memory corruption (a certain crash when an IOLock was claimed
>> seems to be repeatable).
>>
>> One important note which I should have mentioned is that the description
> of
>> the issue in my last past holds good when the member of the class whose
>> placement "cause" the issue was NOT used in any way.
>>
>> sorry for the ambiguities.
>>
>> -----Original Message-----
>> From: Andy O'Meara [mailto:email@hidden]
>> Sent: Thursday, September 08, 2005 9:48 AM
>> To: Philip Lukidis
>> Cc: email@hidden
>> Subject: Re: compiler bug??
>>
>>
>>
>> Please define "all hell broke loose".
>>
>>
>> Andy
>>
>>
>>
>> On 9/8/05 9:21 AM, "Philip Lukidis" <email@hidden> wrote:
>>
>>> I'm pretty new to kext development. Recently, I've encountered something
>>> very strange in one of my classes. Briefly, when I place a member
>> variable
>>> in a certain position within my class, all hell breaks loose. The member
>>> variable is placed within an #ifdef #endif block, and the symbol is
>> defined
>>> with the -D switch. When I removed the #ifdef #endif block, I had no
>>> problems. When I moved the entire #ifdef #endif block to another
> location
>>> within the class, I had no problems. But when I placed the #ifdef #endif
>>> block right under the public keyword, all hell broke loose.
>>>
>>> Changing the optimization level to -O0 had no effect. What are your
>>> thoughts on this? Is there some sort of fatal overflow into my class
>>> memory, something else, or is this a compiler bug? Note the following:
>>>
>>> #ifdef FIRELOGCORE
>>> myClass* mPub;
>>> #else
>>> void* mPub
>>> #endif
>>>
>>> worked, while
>>>
>>> #ifdef FIRELOGCORE
>>> myClass* mPub;
>>> #endif
>>>
>>> did NOT work when placed under the public keyword. Your thoughts on the
>>> subject would be appreciated.
>>>
>>> thanks,
>>>
>>> Philip Lukidis
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Xcode-users 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.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden