• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ARC issue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARC issue


  • Subject: Re: ARC issue
  • From: Bob Cromwell <email@hidden>
  • Date: Wed, 07 Nov 2012 21:45:59 +0800

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:  jne    0x7fff86b2fec7            ; 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, x
> 	0x7fff86b2fe96:  andl   (%r10), x
> 	0x7fff86b2fe99:  movq   16(%r10,%rax,8), %r11
> 	0x7fff86b2fe9e:  incl   x
> 	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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


References: 
 >ARC issue (From: Andreas Grosam <email@hidden>)

  • Prev by Date: Re: ARC issue
  • Next by Date: Re: ARC issue
  • Previous by thread: Re: ARC issue
  • Next by thread: Sony PS3 Move Remote
  • Index(es):
    • Date
    • Thread