ARC issue

[Andreas Grosam]

Xcode 4.5.1, ARC enabled.

I've this C++ member function, for a testing environment (gtest):


NSDictionary* fetchUser(NSNumber* ID, NSError** error)
{
id user = nil;
//@autoreleasepool   // crashes when @autoreleasepool is enabled
{
id data = ...; // response body of a HTTP Response (NSData) or NSError 
object, never nil.
if ([data isKindOfClass:[NSData class]]) {
user = [NSJSONSerialization JSONObjectWithData:data
  options:0
error:error];
}
else if (error) {
*error = data;
}
} // autoreleasepool
return user;
}



The problem here is, if the autorelease pool is **enabled**, I get a crash in 
the caller's code:
NSError* err = nil;
NSDictionary* deletedUser = this->fetchUser(userID, &err);
EXPECT_TRUE(deletedUser == nil);<== the crash occurs **before** 
this statement, but **after** the return statement of the function fetch user.

The debugger does not show a stack frame to confirm this, though.

libobjc.A.dylib`objc_msgSend:
0x7fff86b2fe80:  testq  %rdi, %rdi
0x7fff86b2fe83:  je 0x7fff86b2feb0; objc_msgSend + 48
0x7fff86b2fe85:  testb  $1, %dil
0x7fff86b2fe89:  jne0x7fff86b2fec7; objc_msgSend + 71
0x7fff86b2fe8c:  movq   (%rdi), %r11  
0x7fff86b2fe8f:  pushq  %rax
==> 0x7fff86b2fe90:  movq   16(%r11), %r10  // Thread 1: 
EXC_BAD_ACCESS (code=13, address=0x0)
0x7fff86b2fe94:  movl   %esi, %eax
0x7fff86b2fe96:  andl   (%r10), %eax
0x7fff86b2fe99:  movq   16(%r10,%rax,8), %r11
0x7fff86b2fe9e:  incl   %eax
0x7fff86b2fea0:  testq  %r11, %r11
0x7fff86b2fea3:  je 0x7fff86b2fedb; objc_msgSend + 91
 ...

There is no stack frame.


This has something to do with the error parameter. If I pass nil for the error 
parameter, the crash does not occur anymore.


Any hints?


Thanks in advance!

Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC issue

[Marco Tabini]

I wonder if the problem might be that data is an autoreleased object, which 
automatically gets dealloc'ed at the end of the autorelease pool (as explained 
in the docs). Have you tried replacing

*error = data

with

*error = [data copy]

and seeing what happens?

On 2012-11-07, at 8:05 AM, Andreas Grosam  wrote:

> NSDictionary* fetchUser(NSNumber* ID, NSError** error)
> {
>id user = nil;
>//@autoreleasepool   // crashes when @autoreleasepool is enabled
>{
>id data = ...; // response body of a HTTP Response (NSData) or NSError 
> object, never nil.
>if ([data isKindOfClass:[NSData class]]) {
>user = [NSJSONSerialization JSONObjectWithData:data
>  options:0
>error:error];
>}
>else if (error) {
>*error = data;
>}
>} // autoreleasepool
>return user;
> }

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC issue

[Bob Cromwell]

According to ARC documentation,  out parameter will be changed to auto release 
one:

NSError ** error  will be auto changed to  NSError * __autorelease * error.

So It's expected behavior that crash happens.  An article about this here 
http://blog.pioneeringsoftware.co.uk/2012/03/06/out-parameters-when-arcing

On 2012-11-7, at 下午9:05, Andreas Grosam wrote:

> Xcode 4.5.1, ARC enabled.
> 
> I've this C++ member function, for a testing environment (gtest):
> 
> 
> NSDictionary* fetchUser(NSNumber* ID, NSError** error)
> {
>id user = nil;
>//@autoreleasepool   // crashes when @autoreleasepool is enabled
>{
>id data = ...; // response body of a HTTP Response (NSData) or NSError 
> object, never nil.
>if ([data isKindOfClass:[NSData class]]) {
>user = [NSJSONSerialization JSONObjectWithData:data
>  options:0
>error:error];
>}
>else if (error) {
>*error = data;
>}
>} // autoreleasepool
>return user;
> }
> 
> 
> 
> The problem here is, if the autorelease pool is **enabled**, I get a crash in 
> the caller's code:
>NSError* err = nil;
>NSDictionary* deletedUser = this->fetchUser(userID, &err);
>EXPECT_TRUE(deletedUser == nil);<== the crash occurs 
> **before** this statement, but **after** the return statement of the function 
> fetch user.
> 
> The debugger does not show a stack frame to confirm this, though.
> 
>   libobjc.A.dylib`objc_msgSend:
>   0x7fff86b2fe80:  testq  %rdi, %rdi
>   0x7fff86b2fe83:  je 0x7fff86b2feb0; objc_msgSend + 48
>   0x7fff86b2fe85:  testb  $1, %dil
>   0x7fff86b2fe89:  jne0x7fff86b2fec7; objc_msgSend + 71
>   0x7fff86b2fe8c:  movq   (%rdi), %r11  
>   0x7fff86b2fe8f:  pushq  %rax
> ==>   0x7fff86b2fe90:  movq   16(%r11), %r10  // Thread 1: 
> EXC_BAD_ACCESS (code=13, address=0x0)
>   0x7fff86b2fe94:  movl   %esi, %eax
>   0x7fff86b2fe96:  andl   (%r10), %eax
>   0x7fff86b2fe99:  movq   16(%r10,%rax,8), %r11
>   0x7fff86b2fe9e:  incl   %eax
>   0x7fff86b2fea0:  testq  %r11, %r11
>   0x7fff86b2fea3:  je 0x7fff86b2fedb; objc_msgSend + 91
>...
> 
> There is no stack frame.
> 
> 
> This has something to do with the error parameter. If I pass nil for the 
> error parameter, the crash does not occur anymore.
> 
> 
> Any hints?
> 
> 
> Thanks in advance!
> 
> Andreas
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/bob.cromwell2012%40gmail.com
> 
> This email sent to bob.cromwell2...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC issue

[Ken Thomases]

On Nov 7, 2012, at 7:18 AM, Marco Tabini wrote:

> On 2012-11-07, at 8:05 AM, Andreas Grosam  wrote:
> 
>> NSDictionary* fetchUser(NSNumber* ID, NSError** error)
>> {
>>   id user = nil;
>>   //@autoreleasepool   // crashes when @autoreleasepool is enabled
>>   {
>>   id data = ...; // response body of a HTTP Response (NSData) or NSError 
>> object, never nil.
>>   if ([data isKindOfClass:[NSData class]]) {
>>   user = [NSJSONSerialization JSONObjectWithData:data
>> options:0
>>   error:error];
>>   }
>>   else if (error) {
>>   *error = data;
>>   }
>>   } // autoreleasepool
>>   return user;
>> }
> 
> I wonder if the problem might be that data is an autoreleased object, which 
> automatically gets dealloc'ed at the end of the autorelease pool (as 
> explained in the docs). Have you tried replacing
> 
> *error = data
> 
> with
> 
> *error = [data copy]
> 
> and seeing what happens?

I'm guessing that won't change anything.  The problem, I think, is that for 
parameters like "error" which are returned indirectly via parameters, the 
compiler applies an implicit __autoreleasing qualifier.  Assigning to an 
__autoreleasing variable has the effect of discarding the old value (no 
-release because it was already -autoreleased) and doing a -retain and 
-autorelease on the new value.  Since you've wrapped that in an autorelease 
pool, as that pool is exited, the pointed-to error object is actually released, 
leaving error pointing to an object that may have been deallocated.

At the call site, your "err" object has implicit __strong qualification.  It's 
documented that the compiler resolves the mismatch between the qualifiers by 
(effectively) creating a temporary __autoreleasing variable, passing the 
address of that, and then, on return, assigning that to the __strong variable:

   NSError* err = nil;
   __autoreleasing NSError* temp = err;
   NSDictionary* deletedUser = this->fetchUser(userID, &temp);
   err = temp;
   EXPECT_TRUE(deletedUser == nil);<== the crash occurs **before** 
this statement, but **after** the return statement of the function fetch user.

That assignment causes a -release to err's old value (which is a no-op since 
err is nil) and a -retain to its new value.  I think that -retain is being sent 
to a deallocated object, which is the cause of your crash.

What happens if you enable zombies?

This seems like a problem with ARC.  Ideally, the compiler would understand not 
just that "error" is __autoreleasing but would understand something about its 
"autorelease scope".  That is, it needs to survive to the caller's scope and so 
it needs to survive the @autoreleasepool block, so the compiler should retain 
it in the block and autorelease it outside.

That said, I think the solution may be to declare a local, implicitly strong 
NSError pointer at the same scope as "user", use that within the 
@autoreleasepool block, and then assign from that to the output parameter, if 
it's non-NULL, outside of the block.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Sony PS3 Move Remote

[Eric E. Dolecki]

I am aware of many sources for OS X development using a Kinect camera but
was wondering if it's possible to do similar kinds of things using the Sony
PS3 Move remote control.

I am looking to provide gestural controls using a touch of hardware to
hopefully make the detection finer... the Kinect as it stands today doesn't
seem to do a good enough job. I'd even consider a glove with markers and a
camera - I'm just not aware of any project(s) like that yet.

Thanks,
Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC issue

[Andreas Grosam]

Thank you all for the answers, and your pointers to additional info (@Bob: very 
useful article )!


On 07.11.2012, at 14:50, Ken Thomases wrote:

> 
> I'm guessing that won't change anything.  The problem, I think, is that for 
> parameters like "error" which are returned indirectly via parameters, the 
> compiler applies an implicit __autoreleasing qualifier.

Yes, this is what is happening.

>  Assigning to an __autoreleasing variable has the effect of discarding the 
> old value (no -release because it was already -autoreleased) and doing a 
> -retain and -autorelease on the new value.  Since you've wrapped that in an 
> autorelease pool, as that pool is exited, the pointed-to error object is 
> actually released, leaving error pointing to an object that may have been 
> deallocated.
> 
> At the call site, your "err" object has implicit __strong qualification.  
> It's documented that the compiler resolves the mismatch between the 
> qualifiers by (effectively) creating a temporary __autoreleasing variable, 
> passing the address of that, and then, on return, assigning that to the 
> __strong variable:
> 
>   NSError* err = nil;
>   __autoreleasing NSError* temp = err;
>   NSDictionary* deletedUser = this->fetchUser(userID, &temp);
>   err = temp;
>   EXPECT_TRUE(deletedUser == nil);<== the crash occurs **before** 
> this statement, but **after** the return statement of the function fetch user.
> 
> That assignment causes a -release to err's old value (which is a no-op since 
> err is nil) and a -retain to its new value.  I think that -retain is being 
> sent to a deallocated object, which is the cause of your crash.

This quite accurately describes the scenario, and ...
> What happens if you enable zombies?
… consequently, I got a zombi.

> 
> This seems like a problem with ARC.  Ideally, the compiler would understand 
> not just that "error" is __autoreleasing but would understand something about 
> its "autorelease scope".  That is, it needs to survive to the caller's scope 
> and so it needs to survive the @autoreleasepool block, so the compiler should 
> retain it in the block and autorelease it outside.
This is actually what I was hoping the compiler would understand - that the 
autoreleasing object would be assigned to those autorelease pool which is 
active at the time where the autoreleasing object has been defined (that is, 
the parent pool of the pool defined within fetchUser).
Otherwise, at least, the compiler should issue a warning about the implicit 
conversion from __strong to __autoreleased via a temporary. 

The current behavior makes using output params difficult, especially if they 
are passed through a number of methods - possibly one that wraps code in an 
autorelease pool.

> 
> That said, I think the solution may be to declare a local, implicitly strong 
> NSError pointer at the same scope as "user", use that within the 
> @autoreleasepool block, and then assign from that to the output parameter, if 
> it's non-NULL, outside of the block.
I think I go with this workaround.

Thank you all!

Andreas



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC issue

[Ken Thomases]

On Nov 7, 2012, at 8:33 AM, Andreas Grosam wrote:

> On 07.11.2012, at 14:50, Ken Thomases wrote:
> 
>> This seems like a problem with ARC.  Ideally, the compiler would understand 
>> not just that "error" is __autoreleasing but would understand something 
>> about its "autorelease scope".  That is, it needs to survive to the caller's 
>> scope and so it needs to survive the @autoreleasepool block, so the compiler 
>> should retain it in the block and autorelease it outside.
> This is actually what I was hoping the compiler would understand - that the 
> autoreleasing object would be assigned to those autorelease pool which is 
> active at the time where the autoreleasing object has been defined (that is, 
> the parent pool of the pool defined within fetchUser).

Well, I would not expect the compiler to understand what autorelease pool an 
object should be assigned to.  That's not how autorelease pools work and it's 
also not in the nature of ARC.  ARC concerns itself only with one function, 
method, or block at a time.  Not coincidentally, that's also how Cocoa's manual 
memory management scheme was designed: the developer should only need to 
concern him- or herself with local correctness and be confident that global 
correctness will emerge from that.

I merely think that ARC should know that the __autoreleasing variable has a 
scope which exceeds the @autoreleasepool block in which it was assigned a value 
and do a retain/release at the exit of the @autoreleasepool block to make it 
survive at least until it goes out of scope.

> Otherwise, at least, the compiler should issue a warning about the implicit 
> conversion from __strong to __autoreleased via a temporary. 

I don't think that would be helpful.  That conversion is not the source of the 
problem.  What would you change about the call site in response to such a 
warning?


> The current behavior makes using output params difficult, especially if they 
> are passed through a number of methods - possibly one that wraps code in an 
> autorelease pool.

Agreed.


>> That said, I think the solution may be to declare a local, implicitly strong 
>> NSError pointer at the same scope as "user", use that within the 
>> @autoreleasepool block, and then assign from that to the output parameter, 
>> if it's non-NULL, outside of the block.
> I think I go with this workaround.
> 
> Thank you all!

You're welcome.

Cheers,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sony PS3 Move Remote

[Alex Zavatone]

There is an open source library at the bottom of the Kinect that models a stick 
figure out of the heat signature of the human body(ies) that are in sight.

We played with it a few years back and it wasn't that hard to get going.  Don't 
exactly remember the name though.

On Nov 7, 2012, at 9:05 AM, Eric E. Dolecki wrote:

> I am aware of many sources for OS X development using a Kinect camera but
> was wondering if it's possible to do similar kinds of things using the Sony
> PS3 Move remote control.
> 
> I am looking to provide gestural controls using a touch of hardware to
> hopefully make the detection finer... the Kinect as it stands today doesn't
> seem to do a good enough job. I'd even consider a glove with markers and a
> camera - I'm just not aware of any project(s) like that yet.
> 
> Thanks,
> Eric
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sony PS3 Move Remote

[Eric E. Dolecki]

Thanks. I think I am going to employ some custom hardware to do what I want
to do.



  Google Voice: (508) 656-0622
  Twitter: eric_dolecki  XBoxLive: edolecki  PSN: eric_dolecki
  http://blog.ericd.net



On Wed, Nov 7, 2012 at 9:56 AM, Alex Zavatone  wrote:

> There is an open source library at the bottom of the Kinect that models a
> stick figure out of the heat signature of the human body(ies) that are in
> sight.
>
> We played with it a few years back and it wasn't that hard to get going.
>  Don't exactly remember the name though.
>
> On Nov 7, 2012, at 9:05 AM, Eric E. Dolecki wrote:
>
> > I am aware of many sources for OS X development using a Kinect camera but
> > was wondering if it's possible to do similar kinds of things using the
> Sony
> > PS3 Move remote control.
> >
> > I am looking to provide gestural controls using a touch of hardware to
> > hopefully make the detection finer... the Kinect as it stands today
> doesn't
> > seem to do a good enough job. I'd even consider a glove with markers and
> a
> > camera - I'm just not aware of any project(s) like that yet.
> >
> > Thanks,
> > Eric
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> >
> > This email sent to z...@mac.com
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

GameKit for OS X - no GKSession?

[Eric E. Dolecki]

I have been using GameKit to have two different applications on iPod
Touches communicate with one another - works great. I've seen GameKit
available for OS X Mountain Lion, so I've added that framework to an OS X
project.

I wanted to port my iOS code over and have (at least see if it worked) my
Touch talk with the OS X app using GK. GK for OS X doesn't have GKSession.

Is what I am after possible? How could I port the simple GK code to OS X?

Thanks,
Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Help Indexer error - what does it MEAN?

[Matthias Arndt]

Hi Graham,

I had the same issue today: As Andy mentioned the HTML validation is much 
stricter than in the past, e. g. all  /  /  /  tags have to 
be closed ... I just finished correcting all help files of one project, checked 
them via , and HelpIndexer didn't report any problem 
...

Matthias
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

What does this mean?

[Graham Cox]

I just started getting this error when building with Xcode:

fatal error: file '/Developer/Applications/Xcode 
4.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSScrollView.h'
 has been modified since the precompiled header was built

Huh? I haven't modified that file, and it's been building fine since forever. 
What's going on here, and how do I fix?


--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[SOLVED] Re: What does this mean?

[Graham Cox]

Never mind, Time Machine saved my ass. I must have touched the file somehow 
(why are these writable?).

--Graham


On 08/11/2012, at 2:16 PM, Graham Cox  wrote:

> I just started getting this error when building with Xcode:
> 
> fatal error: file '/Developer/Applications/Xcode 
> 4.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSScrollView.h'
>  has been modified since the precompiled header was built
> 
> Huh? I haven't modified that file, and it's been building fine since forever. 
> What's going on here, and how do I fix?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [SOLVED] Re: What does this mean?

[Marco S Hyman]

On Nov 7, 2012, at 7:23 PM, Graham Cox  wrote:

> Never mind, Time Machine saved my ass. I must have touched the file somehow 
> (why are these writable?).

Bet it's another case of autosave doing unintended harm.  Checking the "Ask to 
keep changes when closing documents" option in General System Preferences helps 
mitigate the issue.

Marc
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [SOLVED] Re: What does this mean?

[Kyle Sluder]

On Nov 7, 2012, at 7:23 PM, Graham Cox  wrote:

> Never mind, Time Machine saved my ass. I must have touched the file somehow 
> (why are these writable?).

Because the headers are located inside the app wrapper instead of 
/System/Library/Frameworks.

I don't know if this issue affects MAS-distributed Xcode installs, since I 
always download and install Xcode from the developer site. I also don't know if 
there's some way the Xcode team could ensure that SDKs are read-only even to 
the user that installed them.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com