Re: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[じょいすじょん]

> On 2016 Dec 7, at 6:27, Carl Hoefs  wrote:
> 
>> 
>> On Dec 6, 2016, at 1:33 PM, Carl Hoefs  
>> wrote:
>> 
>>> On Dec 6, 2016, at 1:24 PM, David Duncan  wrote:
>>> 
>>> Your safest bets are to either clear the delegate of the layer at an 
>>> appropriate time (possibly in your view controller’s dealloc is all that is 
>>> necessary), or to use a UIView instead of a raw CALayer in this case. 
>>> Removing the layer would also suffice, as that would prevent UIKit from 
>>> seeing it at the time in question. Making the layer weak is probably 
>>> causing your reference to deallocate before it can be added to the layer 
>>> tree, which is why it doesn’t display in that case.
>> 
>> Thanks for this explanation, David! 
>> 
>> I've verified that using either of:
>>   [self.layer setDelegate:nil];
>> or
>>   [self.layer removeFromSuperlayer];
>> will prevent the crash. 
> 
> Followup: It turns out that the 'offending' line of code is:
> 
>  [self.layer setDelegate:self];
> 
> If I don't set this, everything still works correctly, and there's no crash 
> at dealloc time.
> 
> -Carl
> 
That sure looks like a circle until you remove something :)
___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[Carl Hoefs]

> On Dec 6, 2016, at 1:33 PM, Carl Hoefs  wrote:
> 
>> On Dec 6, 2016, at 1:24 PM, David Duncan  wrote:
>> 
>> Your safest bets are to either clear the delegate of the layer at an 
>> appropriate time (possibly in your view controller’s dealloc is all that is 
>> necessary), or to use a UIView instead of a raw CALayer in this case. 
>> Removing the layer would also suffice, as that would prevent UIKit from 
>> seeing it at the time in question. Making the layer weak is probably causing 
>> your reference to deallocate before it can be added to the layer tree, which 
>> is why it doesn’t display in that case.
> 
> Thanks for this explanation, David! 
> 
> I've verified that using either of:
>[self.layer setDelegate:nil];
> or
>[self.layer removeFromSuperlayer];
> will prevent the crash. 

Followup: It turns out that the 'offending' line of code is:

  [self.layer setDelegate:self];

If I don't set this, everything still works correctly, and there's no crash at 
dealloc time.

-Carl


___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[Carl Hoefs]

> On Dec 6, 2016, at 1:24 PM, David Duncan  wrote:
> 
> Your safest bets are to either clear the delegate of the layer at an 
> appropriate time (possibly in your view controller’s dealloc is all that is 
> necessary), or to use a UIView instead of a raw CALayer in this case. 
> Removing the layer would also suffice, as that would prevent UIKit from 
> seeing it at the time in question. Making the layer weak is probably causing 
> your reference to deallocate before it can be added to the layer tree, which 
> is why it doesn’t display in that case.

Thanks for this explanation, David! 

I've verified that using either of:
[self.layer setDelegate:nil];
or
[self.layer removeFromSuperlayer];
will prevent the crash. It's just a bit
surprising to me that this is needed...

-Carl


___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[David Duncan]

> On Dec 6, 2016, at 11:51 AM, Doug Hill  wrote:
> 
> I've wondered about this before, but maybe some Objective-C runtime experts 
> know.
> 
> Does writing directly to the ivar backing a property bypass the ARC features 
> of the property. For example, will a strong property be retained if you write 
> directly to the ivar?

Yes, under ARC assigning to a strong ivar and assigning via a strong property 
are identical with respect to the resulting retain count semantics (otherwise 
typically constructed ARC-based setter methods wouldn’t work).

> 
> If not, that's your problem.
> 
> Doug
> 
>> On Dec 6, 2016, at 11:44 AM, Carl Hoefs > <mailto:newsli...@autonomy.caltech.edu>> wrote:
>> 
>> I get the following crash in my iOS 9 app simply by adding a CALayer to the 
>> current view controller's self.view.layer and then dismissing the current 
>> view controller. Simplified code:
>> 
>>   @property (strong,nonatomic) CALayer *layer;
>>   .  .  .
>>   _layer = [[CALayer alloc] init];
>>   [_layer setDelegate: self];
>>   [self.view.layer addSublayer:_layer];
>> 
>> Upon dismissing the VC:
>> 
>>   [self dismissViewControllerAnimated:YES completion:nil];
>> 
>> The following exception occurs:
>> 
>> (lldb) bt
>> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, 
>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
>> address=0xb010)
>>   frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10
>>   frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330
>>   frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118
>>   frame #3: 0x27a2fd06 UIKit`-[UIView dealloc] + 630
>>   frame #4: 0x2336cd98 CoreFoundation`-[__NSDictionaryM dealloc] + 132
>>   frame #5: 0x22c2cf8a libobjc.A.dylib`objc_object::sidetable_release(bool) 
>> + 150
>>   frame #6: 0x22c2d3cc libobjc.A.dylib`(anonymous 
>> namespace)::AutoreleasePoolPage::pop(void*) + 388
>>   frame #7: 0x23363f30 CoreFoundation`_CFAutoreleasePoolPop + 16
>>   frame #8: 0x23415c56 CoreFoundation`__CFRunLoopRun + 1598
>>   frame #9: 0x233641c8 CoreFoundation`CFRunLoopRunSpecific + 516
>>   frame #10: 0x23363fbc CoreFoundation`CFRunLoopRunInMode + 108
>>   frame #11: 0x24980af8 GraphicsServices`GSEventRunModal + 160
>>   frame #12: 0x27a9c434 UIKit`UIApplicationMain + 144
>> * frame #13: 0x001b655e ProteinFold`main(argc=1, argv=0x0043bbc8) + 122 at 
>> main.m:14
>> 
>> If I remove the CALayer first before the 
>> -dismissViewControllerAnimated:completion:, it doesn't crash:
>> 
>>   [layer removeFromSuperlayer];
>> 
>> Why do I need to explicitly remove my added CALayer before dismissing the 
>> VC? Note: If I declare layer as weak, the crash does not occur, but neither 
>> does the layer display onscreen.
>> -Carl
>> 
>> 
>> ___
>> 
>> 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/cocoadev%40breaqz.com 
>> <https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40breaqz.com>
>> 
>> This email sent to cocoa...@breaqz.com <mailto:cocoa...@breaqz.com>
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> <mailto: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 
> <http://lists.apple.com/>
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com 
> <https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com>
> 
> This email sent to david.dun...@apple.com <mailto:david.dun...@apple.com>
--
David Duncan

___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[David Duncan]

> On Dec 6, 2016, at 11:44 AM, Carl Hoefs  
> wrote:
> 
> I get the following crash in my iOS 9 app simply by adding a CALayer to the 
> current view controller's self.view.layer and then dismissing the current 
> view controller. Simplified code:
> 
>@property (strong,nonatomic) CALayer *layer;
>.  .  .
>_layer = [[CALayer alloc] init];
>[_layer setDelegate: self];
>[self.view.layer addSublayer:_layer];
> 
> Upon dismissing the VC:
> 
>[self dismissViewControllerAnimated:YES completion:nil];
> 
> The following exception occurs:
> 
> (lldb) bt
> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, 
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
> address=0xb010)
>frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10
>frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330
>frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118
>frame #3: 0x27a2fd06 UIKit`-[UIView dealloc] + 630
>frame #4: 0x2336cd98 CoreFoundation`-[__NSDictionaryM dealloc] + 132
>frame #5: 0x22c2cf8a libobjc.A.dylib`objc_object::sidetable_release(bool) 
> + 150
>frame #6: 0x22c2d3cc libobjc.A.dylib`(anonymous 
> namespace)::AutoreleasePoolPage::pop(void*) + 388
>frame #7: 0x23363f30 CoreFoundation`_CFAutoreleasePoolPop + 16
>frame #8: 0x23415c56 CoreFoundation`__CFRunLoopRun + 1598
>frame #9: 0x233641c8 CoreFoundation`CFRunLoopRunSpecific + 516
>frame #10: 0x23363fbc CoreFoundation`CFRunLoopRunInMode + 108
>frame #11: 0x24980af8 GraphicsServices`GSEventRunModal + 160
>frame #12: 0x27a9c434 UIKit`UIApplicationMain + 144
>  * frame #13: 0x001b655e ProteinFold`main(argc=1, argv=0x0043bbc8) + 122 at 
> main.m:14

This is due to the confluence of a few UIKit implementation details. The bottom 
line is that UIKit is trying to iterate the subviews of your view controller’s 
view, encounters your layer, and tries to retain the layer’s delegate. Because 
the layer’s delegate is assign (not weak) and the view controller has already 
been deallocated, this explodes taking your app with it.

Your safest bets are to either clear the delegate of the layer at an 
appropriate time (possibly in your view controller’s dealloc is all that is 
necessary), or to use a UIView instead of a raw CALayer in this case. Removing 
the layer would also suffice, as that would prevent UIKit from seeing it at the 
time in question. Making the layer weak is probably causing your reference to 
deallocate before it can be added to the layer tree, which is why it doesn’t 
display in that case.

> 
> If I remove the CALayer first before the 
> -dismissViewControllerAnimated:completion:, it doesn't crash:
> 
>[layer removeFromSuperlayer];
> 
> Why do I need to explicitly remove my added CALayer before dismissing the VC? 
> Note: If I declare layer as weak, the crash does not occur, but neither does 
> the layer display onscreen.
> -Carl
> 
> 
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[Carl Hoefs]

FWIW, it still crashes if I change the code to use self.layer instead of _layer:

   @property (strong,nonatomic) CALayer *layer;
   .  .  .
   self.layer = [[CALayer alloc] init];
   [self.layer setDelegate: self];
   [self.view.layer addSublayer:self.layer];

-Carl

> On Dec 6, 2016, at 12:51 PM, Doug Hill  wrote:
> 
> I've wondered about this before, but maybe some Objective-C runtime experts 
> know.
> 
> Does writing directly to the ivar backing a property bypass the ARC features 
> of the property. For example, will a strong property be retained if you write 
> directly to the ivar?
> 
> If not, that's your problem.
> 
> Doug
> 
>> On Dec 6, 2016, at 11:44 AM, Carl Hoefs  
>> wrote:
>> 
>> I get the following crash in my iOS 9 app simply by adding a CALayer to the 
>> current view controller's self.view.layer and then dismissing the current 
>> view controller. Simplified code:
>> 
>>   @property (strong,nonatomic) CALayer *layer;
>>   .  .  .
>>   _layer = [[CALayer alloc] init];
>>   [_layer setDelegate: self];
>>   [self.view.layer addSublayer:_layer];
>> 
>> Upon dismissing the VC:
>> 
>>   [self dismissViewControllerAnimated:YES completion:nil];
>> 
>> The following exception occurs:
>> 
>> (lldb) bt
>> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, 
>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
>> address=0xb010)
>>   frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10
>>   frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330
>>   frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118
>>   frame #3: 0x27a2fd06 UIKit`-[UIView dealloc] + 630
>>   frame #4: 0x2336cd98 CoreFoundation`-[__NSDictionaryM dealloc] + 132
>>   frame #5: 0x22c2cf8a libobjc.A.dylib`objc_object::sidetable_release(bool) 
>> + 150
>>   frame #6: 0x22c2d3cc libobjc.A.dylib`(anonymous 
>> namespace)::AutoreleasePoolPage::pop(void*) + 388
>>   frame #7: 0x23363f30 CoreFoundation`_CFAutoreleasePoolPop + 16
>>   frame #8: 0x23415c56 CoreFoundation`__CFRunLoopRun + 1598
>>   frame #9: 0x233641c8 CoreFoundation`CFRunLoopRunSpecific + 516
>>   frame #10: 0x23363fbc CoreFoundation`CFRunLoopRunInMode + 108
>>   frame #11: 0x24980af8 GraphicsServices`GSEventRunModal + 160
>>   frame #12: 0x27a9c434 UIKit`UIApplicationMain + 144
>> * frame #13: 0x001b655e ProteinFold`main(argc=1, argv=0x0043bbc8) + 122 at 
>> main.m:14
>> 
>> If I remove the CALayer first before the 
>> -dismissViewControllerAnimated:completion:, it doesn't crash:
>> 
>>   [layer removeFromSuperlayer];
>> 
>> Why do I need to explicitly remove my added CALayer before dismissing the 
>> VC? Note: If I declare layer as weak, the crash does not occur, but neither 
>> does the layer display onscreen.
>> -Carl
>> 
>> 
>> ___
>> 
>> 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/cocoadev%40breaqz.com
>> 
>> This email sent to cocoa...@breaqz.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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[Doug Hill]

I've wondered about this before, but maybe some Objective-C runtime experts 
know.

Does writing directly to the ivar backing a property bypass the ARC features of 
the property. For example, will a strong property be retained if you write 
directly to the ivar?

If not, that's your problem.

Doug

> On Dec 6, 2016, at 11:44 AM, Carl Hoefs  
> wrote:
> 
> I get the following crash in my iOS 9 app simply by adding a CALayer to the 
> current view controller's self.view.layer and then dismissing the current 
> view controller. Simplified code:
> 
>@property (strong,nonatomic) CALayer *layer;
>.  .  .
>_layer = [[CALayer alloc] init];
>[_layer setDelegate: self];
>[self.view.layer addSublayer:_layer];
> 
> Upon dismissing the VC:
> 
>[self dismissViewControllerAnimated:YES completion:nil];
> 
> The following exception occurs:
> 
> (lldb) bt
> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, 
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
> address=0xb010)
>frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10
>frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330
>frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118
>frame #3: 0x27a2fd06 UIKit`-[UIView dealloc] + 630
>frame #4: 0x2336cd98 CoreFoundation`-[__NSDictionaryM dealloc] + 132
>frame #5: 0x22c2cf8a libobjc.A.dylib`objc_object::sidetable_release(bool) 
> + 150
>frame #6: 0x22c2d3cc libobjc.A.dylib`(anonymous 
> namespace)::AutoreleasePoolPage::pop(void*) + 388
>frame #7: 0x23363f30 CoreFoundation`_CFAutoreleasePoolPop + 16
>frame #8: 0x23415c56 CoreFoundation`__CFRunLoopRun + 1598
>frame #9: 0x233641c8 CoreFoundation`CFRunLoopRunSpecific + 516
>frame #10: 0x23363fbc CoreFoundation`CFRunLoopRunInMode + 108
>frame #11: 0x24980af8 GraphicsServices`GSEventRunModal + 160
>frame #12: 0x27a9c434 UIKit`UIApplicationMain + 144
>  * frame #13: 0x001b655e ProteinFold`main(argc=1, argv=0x0043bbc8) + 122 at 
> main.m:14
> 
> If I remove the CALayer first before the 
> -dismissViewControllerAnimated:completion:, it doesn't crash:
> 
>[layer removeFromSuperlayer];
> 
> Why do I need to explicitly remove my added CALayer before dismissing the VC? 
> Note: If I declare layer as weak, the crash does not occur, but neither does 
> the layer display onscreen.
> -Carl
> 
> 
> ___
> 
> 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/cocoadev%40breaqz.com
> 
> This email sent to cocoa...@breaqz.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

iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[Carl Hoefs]

I get the following crash in my iOS 9 app simply by adding a CALayer to the 
current view controller's self.view.layer and then dismissing the current view 
controller. Simplified code:

@property (strong,nonatomic) CALayer *layer;
.  .  .
_layer = [[CALayer alloc] init];
[_layer setDelegate: self];
[self.view.layer addSublayer:_layer];

Upon dismissing the VC:

[self dismissViewControllerAnimated:YES completion:nil];

The following exception occurs:

(lldb) bt
* thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, queue 
= 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
address=0xb010)
frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10
frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330
frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118
frame #3: 0x27a2fd06 UIKit`-[UIView dealloc] + 630
frame #4: 0x2336cd98 CoreFoundation`-[__NSDictionaryM dealloc] + 132
frame #5: 0x22c2cf8a libobjc.A.dylib`objc_object::sidetable_release(bool) + 
150
frame #6: 0x22c2d3cc libobjc.A.dylib`(anonymous 
namespace)::AutoreleasePoolPage::pop(void*) + 388
frame #7: 0x23363f30 CoreFoundation`_CFAutoreleasePoolPop + 16
frame #8: 0x23415c56 CoreFoundation`__CFRunLoopRun + 1598
frame #9: 0x233641c8 CoreFoundation`CFRunLoopRunSpecific + 516
frame #10: 0x23363fbc CoreFoundation`CFRunLoopRunInMode + 108
frame #11: 0x24980af8 GraphicsServices`GSEventRunModal + 160
frame #12: 0x27a9c434 UIKit`UIApplicationMain + 144
  * frame #13: 0x001b655e ProteinFold`main(argc=1, argv=0x0043bbc8) + 122 at 
main.m:14

If I remove the CALayer first before the 
-dismissViewControllerAnimated:completion:, it doesn't crash:

[layer removeFromSuperlayer];

Why do I need to explicitly remove my added CALayer before dismissing the VC? 
Note: If I declare layer as weak, the crash does not occur, but neither does 
the layer display onscreen.
-Carl


___

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: EXC_BAD_ACCESS puzzle when not running as test bundle

[Jonathan Mitchell]

Hmm.
Some more testing has enabled me to remove my Cocoa wrapper altogether and the 
issue persists.
So I will move the query over to the Xcode list.

> On 2 Nov 2015, at 09:45, Jonathan Mitchell  wrote:
> 
> This has me puzzled.
> 
> I have some code that is giving trouble only when built on 10.11.
> I have set up a simple test scenario and it boils down to the following.
> If I execute the same 4 line test code as part of a unit test bundle it works 
> fine.
> If I try and execute the exact same code as part of a foundation tool then it 
> crashes with EXC_BAD_ACCESS.
> 
> The actual code is calling down into Mono and the crash is associated with 
> the AOT compiler (my Cocoa code provides a wrapper to Mono).
> So there is plenty there that could be going askew on 10.11.
> However the fact that the code executes successfully when running as part of 
> test bundle has me stumped.
> The code runs fine on 10.10 and code built on 10.10 runs fine on 10.11.
> 
> Enabling the usual debug stuff (Zombies etc) show up little.
> There are some dlopen() failures logged, but these get logged for the passing 
> unit test case too.
> 
> Does anyone have any idea what could be occurring here?
> I though it was perhaps a SIP related issue, but I have disabled that.
> 
> Thanks
> 
> Jonathan
> 
> 
> 
> 
> ___
> 
> 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/jonathan%40mugginsoft.com
> 
> This email sent to jonat...@mugginsoft.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

EXC_BAD_ACCESS puzzle when not running as test bundle

[Jonathan Mitchell]

This has me puzzled.

I have some code that is giving trouble only when built on 10.11.
I have set up a simple test scenario and it boils down to the following.
If I execute the same 4 line test code as part of a unit test bundle it works 
fine.
If I try and execute the exact same code as part of a foundation tool then it 
crashes with EXC_BAD_ACCESS.

The actual code is calling down into Mono and the crash is associated with the 
AOT compiler (my Cocoa code provides a wrapper to Mono).
So there is plenty there that could be going askew on 10.11.
However the fact that the code executes successfully when running as part of 
test bundle has me stumped.
The code runs fine on 10.10 and code built on 10.10 runs fine on 10.11.

Enabling the usual debug stuff (Zombies etc) show up little.
There are some dlopen() failures logged, but these get logged for the passing 
unit test case too.

Does anyone have any idea what could be occurring here?
I though it was perhaps a SIP related issue, but I have disabled that.

Thanks

Jonathan




___

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: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

[Conrad Shultz]

From this backtrace it looks like you might be trying to perform UI operations 
someplace other than on the main queue, which would cause problems. I'd start 
by checking whether you have:

-Any dispatches to a background queue that might need a dispatch_async to the 
main queue.
-Any observer callbacks/notification handlers that might be called on a 
background queue, and which thus might need a dispatch_async to the main queue.

-Conrad


> On Jun 22, 2015, at 1:21 AM, Devarshi Kulshreshtha 
>  wrote:
> 
> For some reasons it is  at this line as reported by crashlytics:
> 
> _webView = [[UIWebView alloc] initWithFrame:CGRectZero];
> 
> Here is the stack-tace of crashed thread:
> 
> Thread : Crashed: com.apple.root.utility-qos
> 
> 0  JavaScriptCore 0x00018413c9e4 WTFCrash + 72
> 
> 1  JavaScriptCore 0x00018413c9dc WTFCrash + 64
> 
> 2  WebCore0x000190992504
> WebRunLoopUnlock(__CFRunLoopObserver*, unsigned long, void*)
> 
> 3  WebCore0x000190992dac WebThreadLock + 104
> 
> 4  UIKit  0x000187449b2c -[UIWebView
> _webViewCommonInitWithWebView:scalesPageToFit:] + 140
> 
> 5  UIKit  0x00018729dc38 -[UIWebView
> initWithFrame:] + 88
> 
> 6  XYZ   0x0001002e0b60
> -[XYContentViewController viewDidLoad] (XYContentViewController.m:43)
> 
> 7  UIKit  0x000187074958 -[UIViewController
> loadViewIfRequired] + 692
> 
> 8  UIKit  0x000187074668 -[UIViewController
> view] + 32
> 
> 9  XYZ   0x000100032620 -[XYModalViewController
> setViewController:] (XYModalViewController.m:252)
> 
> 10 XYZ   0x00010003279c -[XYModalViewController
> pushModalController:] (XYModalViewController.m:260)
> 
> 11 XYZ   0x000100038b14 -[XYViewController
> presentModalController:] (XYViewController.m:426)
> 
> 12 XYZ   0x0001002fc3d4 __57-[AppDelegate
> application:didFinishLaunchingWithOptions:]_block_invoke451
> (AppDelegate.m:590)
> 
> 13 XYZ   0x0001002fc6c0 __57-[AppDelegate
> application:didFinishLaunchingWithOptions:]_block_invoke499
> (AppDelegate.m:619)
> 
> 14 Foundation 0x000183672574 -[__NSObserver _doit:]
> + 320
> 
> 15 CoreFoundation 0x00018280cddc
> __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
> 
> 16 CoreFoundation 0x00018274b370 _CFXNotificationPost +
> 2060
> 
> 17 Foundation 0x00018366f520 -[NSNotificationCenter
> postNotificationName:object:userInfo:] + 72
> 
> 18 XYZ   0x000100312a50
> __44-[XYListingPriceHistoryCell getPriceAlerts:]_block_invoke_2
> (XYListingPriceHistoryCell.m:77)
> 
> 19 libdispatch.dylib  0x000193e75994
> _dispatch_call_block_and_release + 24
> 
> 20 libdispatch.dylib  0x000193e75954
> _dispatch_client_callout + 16
> 
> 21 libdispatch.dylib  0x000193e82780
> _dispatch_root_queue_drain + 1848
> 
> 22 libdispatch.dylib  0x000193e83c4c
> _dispatch_worker_thread3 + 108
> 
> 23 libsystem_pthread.dylib0x00019405522c _pthread_wqthread + 816


___

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: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

[Devarshi Kulshreshtha]

Thanks Mike.. I will try that and check for memory leaks in my app

On Mon, Jun 22, 2015 at 2:38 PM, Mike Abdullah 
wrote:

> Have you experimented with passing something bigger than CGRectZero for
> the web view’s initial size? Maybe it’s freaking out over that.
>
> Some googling also suggests that the bbadbeef code can mean WebKit
> couldn’t allocate enough memory. Maybe you’re using too much memory in your
> app in total?
>
> > On 22 Jun 2015, at 09:21, Devarshi Kulshreshtha <
> devarshi.bluec...@gmail.com> wrote:
> >
> > Here is my viewDidLoad method:
> >
> > EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0xbbadbeef
> >
> > - (void)viewDidLoad {
> >[super viewDidLoad];
> >
> >[self setTitle:[self.parameters_ get:@"title"]];
> >whiteBGLayer = [[CALayer alloc] init];
> >[whiteBGLayer setBackgroundColor:[UIColor whiteColor].CGColor];
> >[self.view.layer addSublayer:whiteBGLayer];
> >
> >if ([self isWebView]) {
> >_webView = [[UIWebView alloc] initWithFrame:CGRectZero];
> >_webView.delegate = self;
> >_webView.allowsInlineMediaPlayback = YES;
> >_webView.mediaPlaybackRequiresUserAction = NO;
> >[self  checkWebsiteAuthentication];
> >[_webView setTranslatesAutoresizingMaskIntoConstraints:NO];
> >NSString *encodedUrlString = [self
> > toAbsoluteUrlWithNSString:[self.parameters_ get:@"url"]];
> >NSURL *url = [NSURL URLWithString:encodedUrlString];
> >NSURLRequest *request = [NSURLRequest requestWithURL:url];
> >
> >_webView.frame = self.view.frame;
> >[_webView loadRequest:request];
> >[_webView setScalesPageToFit:YES];
> >_webView.scrollView.delegate = self;
> >
> >[self.view addSubview:_webView];
> >[_webView setTranslatesAutoresizingMaskIntoConstraints:NO];
> >[self.view setNeedsUpdateConstraints];
> >} else {
> >self.view.backgroundColor = [UIColor whiteColor];
> >_label = [[UILabel alloc] initWithFrame:CGRectMake(0, 100, 320,
> > 40)];
> >_label.text = @"content view";
> >[self.view addSubview:_label];
> >}
> >
> >if (someName isEqualToString:@“SomeName”]) {
> >UINib *nib = [UINib nibWithNibName:@XYYouTubePlayerContainerView"
> > bundle:nil];
> >self.youTubePlayerContainerView = [[nib instantiateWithOwner:self
> > options:nil] objectAtIndex:0];
> >self.youTubePlayerContainerView.hidden = YES;
> >[self.view addSubview:self.youTubePlayerContainerView];
> >
> >[[NSNotificationCenter defaultCenter] addObserver:self
> > selector:@selector
> > (dismissVideoPlayer)
> >
> > name:UIWindowDidBecomeHiddenNotification
> >   object:nil];
> >}
> >
> >
> > }
> >
> > For some reasons it is  at this line as reported by crashlytics:
> >
> > _webView = [[UIWebView alloc] initWithFrame:CGRectZero];
> >
> > Here is the stack-tace of crashed thread:
> >
> > Thread : Crashed: com.apple.root.utility-qos
> >
> > 0  JavaScriptCore 0x00018413c9e4 WTFCrash + 72
> >
> > 1  JavaScriptCore 0x00018413c9dc WTFCrash + 64
> >
> > 2  WebCore0x000190992504
> > WebRunLoopUnlock(__CFRunLoopObserver*, unsigned long, void*)
> >
> > 3  WebCore0x000190992dac WebThreadLock + 104
> >
> > 4  UIKit  0x000187449b2c -[UIWebView
> > _webViewCommonInitWithWebView:scalesPageToFit:] + 140
> >
> > 5  UIKit  0x00018729dc38 -[UIWebView
> > initWithFrame:] + 88
> >
> > 6  XYZ   0x0001002e0b60
> > -[XYContentViewController viewDidLoad] (XYContentViewController.m:43)
> >
> > 7  UIKit  0x000187074958 -[UIViewController
> > loadViewIfRequired] + 692
> >
> > 8  UIKit  0x000187074668 -[UIViewController
> > view] + 32
> >
> > 9  XYZ   0x000100032620
> -[XYModalViewController
> > setViewController:] (XYModalViewController.m:252)
> >
> > 10 XYZ   0x00010003279c
> -[XYModalViewController
> > pushModalController:] (XYModalViewController.m:260)
> >
> > 11 XYZ  

Re: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

[Mike Abdullah]

Have you experimented with passing something bigger than CGRectZero for the web 
view’s initial size? Maybe it’s freaking out over that.

Some googling also suggests that the bbadbeef code can mean WebKit couldn’t 
allocate enough memory. Maybe you’re using too much memory in your app in total?

> On 22 Jun 2015, at 09:21, Devarshi Kulshreshtha  
> wrote:
> 
> Here is my viewDidLoad method:
> 
> EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0xbbadbeef
> 
> - (void)viewDidLoad {
>[super viewDidLoad];
> 
>[self setTitle:[self.parameters_ get:@"title"]];
>whiteBGLayer = [[CALayer alloc] init];
>[whiteBGLayer setBackgroundColor:[UIColor whiteColor].CGColor];
>[self.view.layer addSublayer:whiteBGLayer];
> 
>if ([self isWebView]) {
>_webView = [[UIWebView alloc] initWithFrame:CGRectZero];
>_webView.delegate = self;
>_webView.allowsInlineMediaPlayback = YES;
>_webView.mediaPlaybackRequiresUserAction = NO;
>[self  checkWebsiteAuthentication];
>[_webView setTranslatesAutoresizingMaskIntoConstraints:NO];
>NSString *encodedUrlString = [self
> toAbsoluteUrlWithNSString:[self.parameters_ get:@"url"]];
>NSURL *url = [NSURL URLWithString:encodedUrlString];
>NSURLRequest *request = [NSURLRequest requestWithURL:url];
> 
>_webView.frame = self.view.frame;
>[_webView loadRequest:request];
>[_webView setScalesPageToFit:YES];
>_webView.scrollView.delegate = self;
> 
>[self.view addSubview:_webView];
>[_webView setTranslatesAutoresizingMaskIntoConstraints:NO];
>[self.view setNeedsUpdateConstraints];
>} else {
>self.view.backgroundColor = [UIColor whiteColor];
>_label = [[UILabel alloc] initWithFrame:CGRectMake(0, 100, 320,
> 40)];
>_label.text = @"content view";
>[self.view addSubview:_label];
>}
> 
>if (someName isEqualToString:@“SomeName”]) {
>UINib *nib = [UINib nibWithNibName:@XYYouTubePlayerContainerView"
> bundle:nil];
>self.youTubePlayerContainerView = [[nib instantiateWithOwner:self
> options:nil] objectAtIndex:0];
>self.youTubePlayerContainerView.hidden = YES;
>[self.view addSubview:self.youTubePlayerContainerView];
> 
>[[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector
> (dismissVideoPlayer)
> 
> name:UIWindowDidBecomeHiddenNotification
>   object:nil];
>}
> 
> 
> }
> 
> For some reasons it is  at this line as reported by crashlytics:
> 
> _webView = [[UIWebView alloc] initWithFrame:CGRectZero];
> 
> Here is the stack-tace of crashed thread:
> 
> Thread : Crashed: com.apple.root.utility-qos
> 
> 0  JavaScriptCore 0x00018413c9e4 WTFCrash + 72
> 
> 1  JavaScriptCore 0x00018413c9dc WTFCrash + 64
> 
> 2  WebCore0x000190992504
> WebRunLoopUnlock(__CFRunLoopObserver*, unsigned long, void*)
> 
> 3  WebCore0x000190992dac WebThreadLock + 104
> 
> 4  UIKit  0x000187449b2c -[UIWebView
> _webViewCommonInitWithWebView:scalesPageToFit:] + 140
> 
> 5  UIKit  0x00018729dc38 -[UIWebView
> initWithFrame:] + 88
> 
> 6  XYZ   0x0001002e0b60
> -[XYContentViewController viewDidLoad] (XYContentViewController.m:43)
> 
> 7  UIKit  0x000187074958 -[UIViewController
> loadViewIfRequired] + 692
> 
> 8  UIKit  0x000187074668 -[UIViewController
> view] + 32
> 
> 9  XYZ   0x000100032620 -[XYModalViewController
> setViewController:] (XYModalViewController.m:252)
> 
> 10 XYZ   0x00010003279c -[XYModalViewController
> pushModalController:] (XYModalViewController.m:260)
> 
> 11 XYZ   0x000100038b14 -[XYViewController
> presentModalController:] (XYViewController.m:426)
> 
> 12 XYZ   0x0001002fc3d4 __57-[AppDelegate
> application:didFinishLaunchingWithOptions:]_block_invoke451
> (AppDelegate.m:590)
> 
> 13 XYZ   0x0001002fc6c0 __57-[AppDelegate
> application:didFinishLaunchingWithOptions:]_block_invoke499
> (AppDelegate.m:619)
> 
> 14 Foundation 0x000183672574 -[__NSObserver _doit:]
> + 320
> 
> 15 CoreFoundation 0x00018280cddc
> __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
> 
> 16 C

EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000bbadbeef crash on UIWebview

[Devarshi Kulshreshtha]

Here is my viewDidLoad method:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0xbbadbeef

- (void)viewDidLoad {
[super viewDidLoad];

[self setTitle:[self.parameters_ get:@"title"]];
whiteBGLayer = [[CALayer alloc] init];
[whiteBGLayer setBackgroundColor:[UIColor whiteColor].CGColor];
[self.view.layer addSublayer:whiteBGLayer];

if ([self isWebView]) {
_webView = [[UIWebView alloc] initWithFrame:CGRectZero];
_webView.delegate = self;
_webView.allowsInlineMediaPlayback = YES;
_webView.mediaPlaybackRequiresUserAction = NO;
[self  checkWebsiteAuthentication];
[_webView setTranslatesAutoresizingMaskIntoConstraints:NO];
NSString *encodedUrlString = [self
 toAbsoluteUrlWithNSString:[self.parameters_ get:@"url"]];
NSURL *url = [NSURL URLWithString:encodedUrlString];
NSURLRequest *request = [NSURLRequest requestWithURL:url];

_webView.frame = self.view.frame;
[_webView loadRequest:request];
[_webView setScalesPageToFit:YES];
_webView.scrollView.delegate = self;

[self.view addSubview:_webView];
[_webView setTranslatesAutoresizingMaskIntoConstraints:NO];
[self.view setNeedsUpdateConstraints];
} else {
self.view.backgroundColor = [UIColor whiteColor];
_label = [[UILabel alloc] initWithFrame:CGRectMake(0, 100, 320,
40)];
_label.text = @"content view";
[self.view addSubview:_label];
}

if (someName isEqualToString:@“SomeName”]) {
UINib *nib = [UINib nibWithNibName:@XYYouTubePlayerContainerView"
bundle:nil];
self.youTubePlayerContainerView = [[nib instantiateWithOwner:self
options:nil] objectAtIndex:0];
self.youTubePlayerContainerView.hidden = YES;
[self.view addSubview:self.youTubePlayerContainerView];

[[NSNotificationCenter defaultCenter] addObserver:self
 selector:@selector
(dismissVideoPlayer)

 name:UIWindowDidBecomeHiddenNotification
   object:nil];
}


}

For some reasons it is  at this line as reported by crashlytics:

_webView = [[UIWebView alloc] initWithFrame:CGRectZero];

Here is the stack-tace of crashed thread:

Thread : Crashed: com.apple.root.utility-qos

0  JavaScriptCore 0x00018413c9e4 WTFCrash + 72

1  JavaScriptCore 0x00018413c9dc WTFCrash + 64

2  WebCore0x000190992504
WebRunLoopUnlock(__CFRunLoopObserver*, unsigned long, void*)

3  WebCore0x000190992dac WebThreadLock + 104

4  UIKit  0x000187449b2c -[UIWebView
_webViewCommonInitWithWebView:scalesPageToFit:] + 140

5  UIKit  0x00018729dc38 -[UIWebView
initWithFrame:] + 88

6  XYZ   0x0001002e0b60
-[XYContentViewController viewDidLoad] (XYContentViewController.m:43)

7  UIKit  0x000187074958 -[UIViewController
loadViewIfRequired] + 692

8  UIKit  0x000187074668 -[UIViewController
view] + 32

9  XYZ   0x000100032620 -[XYModalViewController
setViewController:] (XYModalViewController.m:252)

10 XYZ   0x00010003279c -[XYModalViewController
pushModalController:] (XYModalViewController.m:260)

11 XYZ   0x000100038b14 -[XYViewController
presentModalController:] (XYViewController.m:426)

12 XYZ   0x0001002fc3d4 __57-[AppDelegate
application:didFinishLaunchingWithOptions:]_block_invoke451
(AppDelegate.m:590)

13 XYZ   0x0001002fc6c0 __57-[AppDelegate
application:didFinishLaunchingWithOptions:]_block_invoke499
(AppDelegate.m:619)

14 Foundation 0x000183672574 -[__NSObserver _doit:]
+ 320

15 CoreFoundation 0x00018280cddc
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20

16 CoreFoundation 0x00018274b370 _CFXNotificationPost +
2060

17 Foundation 0x00018366f520 -[NSNotificationCenter
postNotificationName:object:userInfo:] + 72

18 XYZ   0x000100312a50
__44-[XYListingPriceHistoryCell getPriceAlerts:]_block_invoke_2
(XYListingPriceHistoryCell.m:77)

19 libdispatch.dylib  0x000193e75994
_dispatch_call_block_and_release + 24

20 libdispatch.dylib  0x000193e75954
_dispatch_client_callout + 16

21 libdispatch.dylib  0x000193e82780
_dispatch_root_queue_drain + 1848

22 libdispatch.dylib  0x000193e83c4c
_dispatch_worker_thread3 + 108

23 libsystem_pthread.dylib0x00019405522c _pthread_wqthread + 816


I am clueless please suggest.


-- 
Thanks,

Devarshi
___

Cocoa-dev mailing list (Cocoa-

Re: performBatchUpdates: + removeObjectAtIndex: = EXC_BAD_ACCESS

[Jens Alfke]

I suspect your code is getting called on multiple threads, which would 
definitely cause crashes or heap corruption since you haven't added any 
synchronization around your objects. If you don't explicitly use multiple 
threads, maybe the UICollectionView is running your performBatchUpdates: block 
on a background thread? Set some breakpoints and look at what thread(s) they're 
hit on.

—Jens
___

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

performBatchUpdates: + removeObjectAtIndex: = EXC_BAD_ACCESS

[Josh Avant]

Hi everyone,

I'm getting an EXC_BAD_ACCESS from my specific combination of
performBatchUpdates: and removeObjectAtIndex:.

The application is within a framework I'm developing. The framework has a
Mediator object, and multiple Manager dependencies. The Mediator combines
input from all of the Managers in order to control a single
UICollectionView.

Inside the Mediator exists a custom Counter class. The Counter's
implementation is mostly irrelevant, except that it is ultimately backed by
an NSArray.

Here's some code:

FOOMediator.m
```
@interface FOOMediator ()
@property (nonatomic) FOOCounter *counter;
@end

@implementation FOOMediator

- (void)manager:(FOOManager *)manager batchDeleteIndexPaths:(NSArray
*)indexPaths
{
[self.collectionView performBatchUpdates:^{
for (NSIndexPath *indexPath in indexPaths) {
[self manager:manager removeItemAtIndexPath:indexPath];
}
} completion:nil];
}

- (void)manager:(FOOManager *)manager removeItemAtIndexPath:(NSIndexPath
*)indexPath
{
NSString *key = [self keyForManager:manager];

NSUInteger globalIndex = [self.counter
globalIndexForLocalizedIndex:indexPath.item forKey:key];
NSIndexPath *globalIndexPath = [NSIndexPath
indexPathForItem:globalIndex inSection:0];

[self.counter removeKeyAtIndex:globalIndex]; // COMMENTING OUT THIS
LINE STOPS THE EXC_BAD_ACCESS!
[self.collectionView deleteItemsAtIndexPaths:@[globalIndexPath]];
}

@end
```

FOOCounter.m
```
@interface FOOCounter ()
@property (nonatomic) NSMutableArray *keys;
@end

@implementation FOOCounter

- (void)removeKeyAtIndex:(NSUInteger)index
{
[self.keys removeObjectAtIndex:index];
}

@end
```

The problem arises when a Manager attempts to batch insert + batch delete
sets of items multiple times, in quick succession.

In this situation, an EXC_BAD_ACCESS is thrown, caused by the line noted
above ([self.counter removeKeyAtIndex...]). If I uncomment that line, the
exception stops getting thrown, and everything works.

Enabling Guard Malloc reports, on the line of performBatchUpdates, a buffer
underrun situation:
```
GuardMalloc[Foobar-62390]: free: header for block 0x12001ecff0-0x12001ed000
has been trashed by a buffer underrun. Header magic value at 0x12001ecfe8
is 0x0009, not 0xdeadbeefdeadbeef.  Try running with
MALLOC_PROTECT_BEFORE to catch this error immediately as it happens.
```
...and running with MALLOC_PROTECT_BEFORE will also break on
performBatchUpdates:.

Could anyone offer any suggestions as to why this is happening? Any ideas
how to mitigate this? Thanks in advanced for any help!

-Josh
___

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: EXC_BAD_ACCESS in NSData

[Scott Ribe]

On May 28, 2014, at 10:24 PM, Uli Kusterer  wrote:

> That said, if you want to be really endian-safe, use an XML file format saved 
> as UTF-8 like Property Lists. Most portable format there is. :-)

Thanks a lot. I have to go rinse out my mouth now.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: EXC_BAD_ACCESS in NSData

[Charles Srstka]

On May 28, 2014, at 11:24 PM, Uli Kusterer  wrote:

> Or change struct alignment or the size of ints or … I’ve been programming for 
> a couple of days, I’ve taken this into account. But I’d rather retroactively 
> go and fix something (you have to re-test when porting to a new platform 
> anyway) than go all architecture astronaut and prepare for changes in ABI 
> that may or may never happen. In a well-architected code-base, the code that 
> is affected by endian-ness is separate from the other code anyway. 

The time taken to add a simple CFSwapInt(16|32|64)(Big|Little)ToHost is pretty 
much trivial. It's not "architecture astronaut" in the least, and it's 
certainly less work than fixing this crap after the fact, and you end up with 
something that is actually semantically correct.

> That said, if you want to be really endian-safe, use an XML file format saved 
> as UTF-8 like Property Lists. Most portable format there is. :-)

Oh, no argument from me. Sometimes you don't control the format, though.

Charles

___

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: EXC_BAD_ACCESS in NSData

[Charles Srstka]

On May 27, 2014, at 3:51 PM, Greg Parker  wrote:

> On May 27, 2014, at 12:52 PM, Charles Srstka  wrote:
>> On May 27, 2014, at 2:08 PM, Greg Parker  wrote:
>>> On May 26, 2014, at 8:28 PM, Charles Srstka  
>>> wrote:
 On May 26, 2014, at 7:43 PM, Uli Kusterer  
 wrote:
> Regarding endian-swapping, that depends on the file format. If you wrote 
> that file yourself, you don’t usually need to do any swapping.
 
 That's true. For example, back in the PowerPC days, we never had to 
 endian-swap our file formats, because we knew that our file format was 
 created on a Mac, and Macs always used big-endian, and it wasn't as if 
 Apple was ever going to do anything crazy like switch to Intel or anything.
 
 Nowadays, of course, we can be assured that our code will always run on 
 Intel processors, because *obviously* there's no reason your code would 
 ever need to run on something like ARM.
>>> 
>>> Note that most ARM platforms are little-endian nowadays, including iOS.
>>> 
>>> Untested code is incorrect code. Don't write endian-swapping code that you 
>>> can't test because you aren't using any other-endian platforms today. It's 
>>> expensive to spend engineer-hours to write endian code that is untested and 
>>> therefore incorrect, or to write endian code plus endian tests in the fear 
>>> that you'll need to port to such a platform someday.
>>> 
>>> Do you try to handle platforms where arithmetic is not two's-complement or 
>>> where bytes are not 8 bits? I don't. The Next Big Thing might use them, but 
>>> that's not the way to bet. Endianness is on the same scale, although 
>>> admittedly not at that extreme.
>>> 
>>> If you're paranoid or you like portability, you should use a reading and 
>>> writing abstraction that can be changed into an endian transformation if 
>>> necessary in the future. More than that is unlikely to be worth the 
>>> investment until you receive a credible threat of an other-endian platform 
>>> that you care about.
>> 
>> I've been bitten by that advice in the past, during the Intel transition. 
>> Going through a large codebase trying to find every occurrence where you've 
>> transferred data directly to/from a buffer is not fun, and definitely wastes 
>> a lot more engineer-hours than properly annotating code as you write it. 
>> Writing something like:
>> 
>> uint32_t foo = CFSwapInt32LittleToHost(*(uint32_t *)bytes);
>> 
>> instead of:
>> 
>> uint32_t foo = *(uint32_t *)bytes;
>> 
>> scarcely spends "engineer-hours", as it costs nothing more than the 2 
>> seconds taken to type the macro. It's not "untested" per se, since it's 
>> doing exactly what it says on the tin; it converts the endianness of the 
>> input data to the endianness of the host machine. It just so happens that 
>> this time, they're equal, so the macro doesn't have to do anything.
> 
> It absolutely is untested. The code is intended to work when the host machine 
> is of either endianness. It has only been executed with one such endianness. 
> The other-endian configuration is untested.

The part that's actually going to be running on the end-user's machine; i.e. 
the part that I've compiled, is absolutely tested. It reads a value from a 
file, it turns it into an integer in the host endian (in this case, little 
endian), and it's completely tested. When I port the code to another platform, 
that port will obviously need to be tested all over again, as it would *anyway*.

If I were compiling the app for other platforms right now, and then not testing 
it on the platforms I'd compiled it for, you'd have a point.

Charles

___

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: EXC_BAD_ACCESS in NSData

[Uli Kusterer]

On 26 May 2014, at 20:28, Charles Srstka  wrote:
> On May 26, 2014, at 7:43 PM, Uli Kusterer  
> wrote:
>> Regarding endian-swapping, that depends on the file format. If you wrote 
>> that file yourself, you don’t usually need to do any swapping.
> 
> That's true. For example, back in the PowerPC days, we never had to 
> endian-swap our file formats, because we knew that our file format was 
> created on a Mac, and Macs always used big-endian, and it wasn't as if Apple 
> was ever going to do anything crazy like switch to Intel or anything.

 Or change struct alignment or the size of ints or … I’ve been programming for 
a couple of days, I’ve taken this into account. But I’d rather retroactively go 
and fix something (you have to re-test when porting to a new platform anyway) 
than go all architecture astronaut and prepare for changes in ABI that may or 
may never happen. In a well-architected code-base, the code that is affected by 
endian-ness is separate from the other code anyway. 

 Also, endian-ness did not change in the switch from 680x0 to PowerPC for 
instance, so in my book that was just a fluke. :-p

 That said, if you want to be really endian-safe, use an XML file format saved 
as UTF-8 like Property Lists. Most portable format there is. :-)

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: EXC_BAD_ACCESS in NSData

[Graham Cox]

On 28 May 2014, at 5:52 am, Charles Srstka  wrote:

> a) 'bar' is a later addition to the file format, added some time after the 
> app was ported to Intel, and thus is in little-endian format whereas the 
> older parts of the file are in big-endian (and yes, I've seen formats that do 
> this), or


ArcGIS files, for example, have mixtures of fields in big and little-endian 
order. I was a bit gobsmacked when I saw that first time.

--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

Re: EXC_BAD_ACCESS in NSData

[Jens Alfke]

On May 27, 2014, at 12:08 PM, Greg Parker  wrote:

> Untested code is incorrect code. Don't write endian-swapping code that you 
> can't test because you aren't using any other-endian platforms today.

I disagree. There is a strong, longstanding  convention for cross-platform 
binary data formats (file or network) to store numbers in “network byte order” 
(big-endian). If you write code for x86 or current-day ARM that reads or writes 
such a format, you _need_ to endian-swap just to implement the format 
correctly. And if you’re defining a new format, it probably makes sense to 
follow convention and use big-endian.

If your code interoperates with an existing correct implementation (by 
reading/writing the same data), you have de facto tested your byte-swapping 
code. (If you’d forgotten to add some swaps, your code would break because 
you’d be reading or writing flipped numbers.)

> It's expensive to spend engineer-hours to write endian code that is untested 
> and therefore incorrect, or to write endian code plus endian tests in the 
> fear that you'll need to port to such a platform someday.

If you later need to make the code portable to other-endian architectures, the 
code that includes endian-swapping is very likely to work, whereas the code 
that doesn’t is guaranteed not to work. The code without swapping is also going 
to have to be reviewed carefully to find all the places where the swaps should 
be added, which could be pretty nightmarish especially if its original author 
isn’t available anymore.

Your advice is pretty much like advising iOS programmers (pre-2013) to ignore 
integer and pointer sizes, and just use ‘int’ for everything instead of size_t 
or uint32_t, because they hadn’t actually tested their code on a 64-bit CPU. 
People who’d followed that advice would definitely have had a hard time porting 
their apps to the iPhone 5s.

—Jens
___

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: EXC_BAD_ACCESS in NSData

[Greg Parker]

On May 27, 2014, at 12:52 PM, Charles Srstka  wrote:
> On May 27, 2014, at 2:08 PM, Greg Parker  wrote:
>> On May 26, 2014, at 8:28 PM, Charles Srstka  wrote:
>>> On May 26, 2014, at 7:43 PM, Uli Kusterer  
>>> wrote:
 Regarding endian-swapping, that depends on the file format. If you wrote 
 that file yourself, you don’t usually need to do any swapping.
>>> 
>>> That's true. For example, back in the PowerPC days, we never had to 
>>> endian-swap our file formats, because we knew that our file format was 
>>> created on a Mac, and Macs always used big-endian, and it wasn't as if 
>>> Apple was ever going to do anything crazy like switch to Intel or anything.
>>> 
>>> Nowadays, of course, we can be assured that our code will always run on 
>>> Intel processors, because *obviously* there's no reason your code would 
>>> ever need to run on something like ARM.
>> 
>> Note that most ARM platforms are little-endian nowadays, including iOS.
>> 
>> Untested code is incorrect code. Don't write endian-swapping code that you 
>> can't test because you aren't using any other-endian platforms today. It's 
>> expensive to spend engineer-hours to write endian code that is untested and 
>> therefore incorrect, or to write endian code plus endian tests in the fear 
>> that you'll need to port to such a platform someday.
>> 
>> Do you try to handle platforms where arithmetic is not two's-complement or 
>> where bytes are not 8 bits? I don't. The Next Big Thing might use them, but 
>> that's not the way to bet. Endianness is on the same scale, although 
>> admittedly not at that extreme.
>> 
>> If you're paranoid or you like portability, you should use a reading and 
>> writing abstraction that can be changed into an endian transformation if 
>> necessary in the future. More than that is unlikely to be worth the 
>> investment until you receive a credible threat of an other-endian platform 
>> that you care about.
> 
> I've been bitten by that advice in the past, during the Intel transition. 
> Going through a large codebase trying to find every occurrence where you've 
> transferred data directly to/from a buffer is not fun, and definitely wastes 
> a lot more engineer-hours than properly annotating code as you write it. 
> Writing something like:
> 
> uint32_t foo = CFSwapInt32LittleToHost(*(uint32_t *)bytes);
> 
> instead of:
> 
> uint32_t foo = *(uint32_t *)bytes;
> 
> scarcely spends "engineer-hours", as it costs nothing more than the 2 seconds 
> taken to type the macro. It's not "untested" per se, since it's doing exactly 
> what it says on the tin; it converts the endianness of the input data to the 
> endianness of the host machine. It just so happens that this time, they're 
> equal, so the macro doesn't have to do anything.

It absolutely is untested. The code is intended to work when the host machine 
is of either endianness. It has only been executed with one such endianness. 
The other-endian configuration is untested.


> It also provides a nice parallelism with other pieces of code where you are 
> reading big-endian data, and thus most certainly *do* need to swap, and very 
> importantly, it documents the programmer's intentions.


Documentation is valuable. I suggest the correct level of documentation for new 
code is an annotation that says "this operation is writing to a file or wire 
protocol". If you need an endian conversion someday then it would go there. 
Annotations of actual endian-conversion operations are untrustworthy. 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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: EXC_BAD_ACCESS in NSData

[Charles Srstka]

On May 27, 2014, at 2:08 PM, Greg Parker  wrote:

> On May 26, 2014, at 8:28 PM, Charles Srstka  wrote:
>> On May 26, 2014, at 7:43 PM, Uli Kusterer  
>> wrote:
>>> Regarding endian-swapping, that depends on the file format. If you wrote 
>>> that file yourself, you don’t usually need to do any swapping.
>> 
>> That's true. For example, back in the PowerPC days, we never had to 
>> endian-swap our file formats, because we knew that our file format was 
>> created on a Mac, and Macs always used big-endian, and it wasn't as if Apple 
>> was ever going to do anything crazy like switch to Intel or anything.
>> 
>> Nowadays, of course, we can be assured that our code will always run on 
>> Intel processors, because *obviously* there's no reason your code would ever 
>> need to run on something like ARM.
> 
> Note that most ARM platforms are little-endian nowadays, including iOS.
> 
> Untested code is incorrect code. Don't write endian-swapping code that you 
> can't test because you aren't using any other-endian platforms today. It's 
> expensive to spend engineer-hours to write endian code that is untested and 
> therefore incorrect, or to write endian code plus endian tests in the fear 
> that you'll need to port to such a platform someday.
> 
> Do you try to handle platforms where arithmetic is not two's-complement or 
> where bytes are not 8 bits? I don't. The Next Big Thing might use them, but 
> that's not the way to bet. Endianness is on the same scale, although 
> admittedly not at that extreme.
> 
> If you're paranoid or you like portability, you should use a reading and 
> writing abstraction that can be changed into an endian transformation if 
> necessary in the future. More than that is unlikely to be worth the 
> investment until you receive a credible threat of an other-endian platform 
> that you care about.

I've been bitten by that advice in the past, during the Intel transition. Going 
through a large codebase trying to find every occurrence where you've 
transferred data directly to/from a buffer is not fun, and definitely wastes a 
lot more engineer-hours than properly annotating code as you write it. Writing 
something like:

uint32_t foo = CFSwapInt32LittleToHost(*(uint32_t *)bytes);

instead of:

uint32_t foo = *(uint32_t *)bytes;

scarcely spends "engineer-hours", as it costs nothing more than the 2 seconds 
taken to type the macro. It's not "untested" per se, since it's doing exactly 
what it says on the tin; it converts the endianness of the input data to the 
endianness of the host machine. It just so happens that this time, they're 
equal, so the macro doesn't have to do anything. It also provides a nice 
parallelism with other pieces of code where you are reading big-endian data, 
and thus most certainly *do* need to swap, and very importantly, it documents 
the programmer's intentions.

Suppose you are looking at a chunk of code from a legacy codebase which goes 
back a large number of years. In this codebase, you see this:

int32_t foo = CFSwapInt32BigToHost(*(uint32_t *)someChunkOfData);
int32_t bar = *(uint32_t *)someOtherChunkOfData;

Does this mean:

a) 'bar' is a later addition to the file format, added some time after the app 
was ported to Intel, and thus is in little-endian format whereas the older 
parts of the file are in big-endian (and yes, I've seen formats that do this), 
or

b) 'bar' is supposed to be in big-endian just like the rest of the file format, 
and the line was originally added in the PowerPC days, and now it's just a bug 
that no one's caught yet?

Without explicit annotations, you don't know the answer to this question, but 
if the original developer had put the appropriate macro in there, you'd know 
exactly what kind of data s/he intended that line to be reading, and then you'd 
know how to maintain it in the future.

Charles

___

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: EXC_BAD_ACCESS in NSData

[Greg Parker]

On May 26, 2014, at 8:28 PM, Charles Srstka  wrote:
> On May 26, 2014, at 7:43 PM, Uli Kusterer  
> wrote:
>> Regarding endian-swapping, that depends on the file format. If you wrote 
>> that file yourself, you don’t usually need to do any swapping.
> 
> That's true. For example, back in the PowerPC days, we never had to 
> endian-swap our file formats, because we knew that our file format was 
> created on a Mac, and Macs always used big-endian, and it wasn't as if Apple 
> was ever going to do anything crazy like switch to Intel or anything.
> 
> Nowadays, of course, we can be assured that our code will always run on Intel 
> processors, because *obviously* there's no reason your code would ever need 
> to run on something like ARM.

Note that most ARM platforms are little-endian nowadays, including iOS.

Untested code is incorrect code. Don't write endian-swapping code that you 
can't test because you aren't using any other-endian platforms today. It's 
expensive to spend engineer-hours to write endian code that is untested and 
therefore incorrect, or to write endian code plus endian tests in the fear that 
you'll need to port to such a platform someday.

Do you try to handle platforms where arithmetic is not two's-complement or 
where bytes are not 8 bits? I don't. The Next Big Thing might use them, but 
that's not the way to bet. Endianness is on the same scale, although admittedly 
not at that extreme.

If you're paranoid or you like portability, you should use a reading and 
writing abstraction that can be changed into an endian transformation if 
necessary in the future. More than that is unlikely to be worth the investment 
until you receive a credible threat of an other-endian platform that you care 
about.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: EXC_BAD_ACCESS in NSData

[Charles Srstka]

On May 26, 2014, at 7:43 PM, Uli Kusterer  wrote:

> Regarding endian-swapping, that depends on the file format. If you wrote that 
> file yourself, you don’t usually need to do any swapping.

That's true. For example, back in the PowerPC days, we never had to endian-swap 
our file formats, because we knew that our file format was created on a Mac, 
and Macs always used big-endian, and it wasn't as if Apple was ever going to do 
anything crazy like switch to Intel or anything.

Nowadays, of course, we can be assured that our code will always run on Intel 
processors, because *obviously* there's no reason your code would ever need to 
run on something like ARM.

Hmm.

Charles

___

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: EXC_BAD_ACCESS in NSData

[Graham Cox]

On 27 May 2014, at 10:13 am, Jens Alfke  wrote:

> No, it’s extremely common to have a data format where a variable-length field 
> is prefixed with its length. That looks like what this code is trying to read.

Alright, but you have to know that. I was looking at the code from a general 
standpoint, where its format was unknown - just a blob of data. Also, just 
reading the bytes blindly doesn't take into account endianness, though you and 
Roland do mention that. 

What I prefer to do when parsing blobs of data like this is declare types that 
represent chunks of the format, such as a struct that matches the header (being 
careful about matching the padding used by the file) then cast or copy the data 
buffer, taking into account endianness, into that type. It makes the code a lot 
more readable, because you are not just reading from a arbitrary offset, but 
are using a named field.

--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

Re: EXC_BAD_ACCESS in NSData

[Uli Kusterer]

On 26 May 2014, at 16:20, Graham Cox  wrote:
> On 27 May 2014, at 12:54 am, Roland King  wrote:
>> datasize = *((unsigned int*)bytes); 
>> 
>> is a bit closer to what you might want but is endian-unaware. 
> 
> That's just as wrong - you are using the first few bytes of the data as the 
> length, which it certainly isn't (except for possibly a very few special 
> cases that just so happen to have the length as the first field of the data).

 It’s not a general truth, true, but from what the OP mentioned, he’s 
sequentially reading stuff from his big NSData:

>datasize = (unsigned int)bytes; //This is the length of 
> the data indicated in the data structure from the capture.

 So there you need to correctly cast the start of the data into a pointer to 
the right size of int (in general, you’d use some stable type like uint32_t 
instead of unsigned int for portability, though), and then de-reference it to 
read.

 Regarding endian-swapping, that depends on the file format. If you wrote that 
file yourself, you don’t usually need to do any swapping.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: EXC_BAD_ACCESS in NSData

[Jens Alfke]

On May 26, 2014, at 4:20 PM, Graham Cox  wrote:

> That's just as wrong - you are using the first few bytes of the data as the 
> length, which it certainly isn't (except for possibly a very few special 
> cases that just so happen to have the length as the first field of the data).

No, it’s extremely common to have a data format where a variable-length field 
is prefixed with its length. That looks like what this code is trying to read.

The right way to do this would be something like:
uint32_t length = *(uint32_t*)bytes;
length = CFSwapInt32BigToHost(length);
You need to be explicit about the size of integer in use (“int” has different 
sizes on different platforms) and you need to convert from the byte-order used 
in the file format (which is almost always big-endian.)

—Jens
___

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: EXC_BAD_ACCESS in NSData

[Graham Cox]

On 27 May 2014, at 12:54 am, Roland King  wrote:

> datasize = *((unsigned int*)bytes); 
> 
> is a bit closer to what you might want but is endian-unaware. 

That's just as wrong - you are using the first few bytes of the data as the 
length, which it certainly isn't (except for possibly a very few special cases 
that just so happen to have the length as the first field of the data).

--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

Re: EXC_BAD_ACCESS in NSData

[Jens Alfke]

On May 26, 2014, at 6:02 AM, Pax <45rpmli...@googlemail.com> wrote:

> When this gets run, I get EXC_BAD_ACCESS code = 2 here.  I'm demonstrably 
> reading less data than the file contains, and I've been able to read through 
> the file successfully up to this point.  Please could someone suggest to me 
> what might be going wrong here?

Use the debugger to look at the values of the relevant variables, especially 
dataSize.
Since the result is a crash instead of an exception, the NSRange you create is 
valid; so I assume it’s just larger than your buffer so the copy runs off the 
end into unmapped address space.

Also, what exactly is the type of ‘bytes’? If it’s a pointer to a malloced 
buffer, you shouldn’t be passing its address, rather its value, otherwise 
you’re going to copy into the stack and blow up.

—Jens
___

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: EXC_BAD_ACCESS in NSData

[Scott Ribe]

On May 26, 2014, at 10:06 AM, Pax <45rpmli...@googlemail.com> wrote:

> As I say though, I think that the solution I posted is the better solution 
> anyway - since who wants a copy, with the additional overhead that a copy 
> entails, when you don't need to have one?

Absolutely. (For read-only access.)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: EXC_BAD_ACCESS in NSData

[Pax]

Shameful.  I need more sleep! :-)  I also need to reread my code more carefully 
before asking questions.  

As I say though, I think that the solution I posted is the better solution 
anyway - since who wants a copy, with the additional overhead that a copy 
entails, when you don't need to have one?

On 26 May 2014, at 16:33, Roland King  wrote:

> Too true. That was a lot of bugs in 4 lines!
> 
>> On 26 May, 2014, at 11:18 pm, Scott Ribe  wrote:
>> 
>>> On May 26, 2014, at 9:05 AM, Roland King  wrote:
>>> 
>>> The first one of those is ok...
>> 
>> No, it's not--take a closer look ;-)
>> 
>>> unsigned char* databuffer = (unsigned char*)malloc(datasize);
>>> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
>>> datasize)];
>> 
>> 
>> -- 
>> Scott Ribe
>> scott_r...@elevated-dev.com
>> http://www.elevated-dev.com/
>> (303) 722-0567 voice
>> 
>> 
>> 
>> 


___

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: EXC_BAD_ACCESS in NSData

[Scott Ribe]

On May 26, 2014, at 9:32 AM, Uli Kusterer  wrote:

> Oh, and as Roland wrote, don’t forget to free() the pointer once you’re done 
> with it.

But, just to be 100% clear, *not* the one you get from calling the bytes method 
;-)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: EXC_BAD_ACCESS in NSData

[Roland King]

Too true. That was a lot of bugs in 4 lines!

> On 26 May, 2014, at 11:18 pm, Scott Ribe  wrote:
> 
>> On May 26, 2014, at 9:05 AM, Roland King  wrote:
>> 
>> The first one of those is ok...
> 
> No, it's not--take a closer look ;-)
> 
>> unsigned char* databuffer = (unsigned char*)malloc(datasize);
>> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
>> datasize)];
> 
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
> 
> 
> 
> 

___

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: EXC_BAD_ACCESS in NSData

[Uli Kusterer]

On 26 May 2014, at 06:44, Pax <45rpmli...@googlemail.com> wrote:
> Apologies - the obvious important detail, and I missed it out entirely.  I 
> have tried both of the following with the same result:
> 
>   unsigned char* databuffer = (unsigned char*)malloc(datasize);
>   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
> datasize)]; // Packet content

 As Scott says, you’re passing the address of a variable containing the address 
of the allocated memory, instead of just giving it the address of the allocated 
memory as you should. It’s like being asked to enter your address into a form, 
and instead you give them the address of a friend where they’re supposed to ask 
for your address. Since they don’t expect that, they will just deliver your 
order to your friend. No surprise it doesn’t work.

> and 
> 
>   unsigned char* bytes;
>   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
> // Packet content
> 
> Either way, I get the same result.

 This makes no sense. You’re still giving the address of a variable that can 
contain an address (which is wrong), but even if you didn’t: Since you never 
actually write an address into ‘bytes’ you get a random value (whatever 
happened to be in that location in memory at the time).

 You may want to read some more about memory, pointers etc. (like the parts I 
wrote in my ‘Masters of the Void’ C tutorial: 
http://masters-of-the-void.com/book5.htm) to make sure you have a correct 
understanding. Something still seems to be fuzzy in your head.

Oh, and as Roland wrote, don’t forget to free() the pointer once you’re done 
with it.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: EXC_BAD_ACCESS in NSData

[Scott Ribe]

On May 26, 2014, at 9:05 AM, Roland King  wrote:

> The first one of those is ok...

No, it's not--take a closer look ;-)

> unsigned char* databuffer = (unsigned char*)malloc(datasize);
> [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
> datasize)];


-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: EXC_BAD_ACCESS in NSData

[Roland King]

The first one of those is ok - as long as you remember to free databuffer 
later. The second is wrong, the argument to getBytes:range: has to be an 
allocated buffer of size at least the length of the range you pass in. That 
second one is just copying data to a random place in memory, probably zero. 

On 26 May, 2014, at 9:44 pm, Pax <45rpmli...@googlemail.com> wrote:

> Apologies - the obvious important detail, and I missed it out entirely.  I 
> have tried both of the following with the same result:
> 
>   unsigned char* databuffer = (unsigned char*)malloc(datasize);
>   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
> datasize)]; // Packet content
> 
> and 
> 
>   unsigned char* bytes;
>   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
> // Packet content
> 
> Either way, I get the same result.
> 
> 
> 
> On 26 May 2014, at 14:16, Uli Kusterer  wrote:
> 
>> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
>>> This is my snippet of code:
>>>  [datastream getBytes:&bytes 
>>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>>>  positionCounter+= datasize;
>> 
>> What is bytes declared as, and what do you initialize it to?
>> 
>> Cheers,
>> -- Uli Kusterer
>> “The Witnesses of TeachText are everywhere...”
>> http://zathras.de
>> 
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: EXC_BAD_ACCESS in NSData

[Scott Ribe]

On May 26, 2014, at 8:43 AM, Pax <45rpmli...@googlemail.com> wrote:

> I should, I know, find out what was going wrong initially - but since I'd 
> rather not have a copy anyway, this really is the all-round better solution.

What was wrong was that instead of passing the address of the buffer you 
allocated, you were passing the address of the variable which held the address 
of the buffer.

But beyond that, the fact that you even tried:

unsigned char* bytes;
[datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; // 
Packet content

and weren't sure whether it would work, indicates that you have a big gap in 
understanding pointers & memory, and this needs to be fixed or you'll continue 
to create crashing bugs, some of which will not be nice enough to show up every 
time you run the code ;-)

If you haven't already, studying a good tutorial on C or Objective-C is in 
order. If you have, then reviewing the sections on pointers and dynamic memory 
is in order.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: EXC_BAD_ACCESS in NSData

[Roland King]

So you have 

unsigned char *bytes; 

and then

datasize = (unsigned int)bytes;

which sets datasize to the address of bytes cast to an unsigned integer which 
has nothing to do with the data in bytes at all and in some cases just 
truncates the address (OSX for instance)

datasize = *((unsigned int*)bytes); 

is a bit closer to what you might want but is endian-unaware. 


On 26 May, 2014, at 9:44 pm, Pax <45rpmli...@googlemail.com> wrote:

> Apologies - the obvious important detail, and I missed it out entirely.  I 
> have tried both of the following with the same result:
> 
>   unsigned char* databuffer = (unsigned char*)malloc(datasize);
>   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
> datasize)]; // Packet content
> 
> and 
> 
>   unsigned char* bytes;
>   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
> // Packet content
> 
> Either way, I get the same result.
> 
> 
> 
> On 26 May 2014, at 14:16, Uli Kusterer  wrote:
> 
>> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
>>> This is my snippet of code:
>>>  [datastream getBytes:&bytes 
>>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>>>  positionCounter+= datasize;
>> 
>> What is bytes declared as, and what do you initialize it to?
>> 
>> Cheers,
>> -- Uli Kusterer
>> “The Witnesses of TeachText are everywhere...”
>> http://zathras.de
>> 
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: EXC_BAD_ACCESS in NSData

[Pax]

Just to answer my own question, I find that:

bytes=[[datastream subdataWithRange:NSMakeRange(positionCounter, 
datasize)]bytes];

Works perfectly.

I should, I know, find out what was going wrong initially - but since I'd 
rather not have a copy anyway, this really is the all-round better solution.

On 26 May 2014, at 15:25, Sandy McGuffog  wrote:

> Well,
> 
> I find your code to be a bit confusing, but I’d say that both of those are 
> wrong. I think that what you need is:
> 
>  unsigned char* databuffer = (unsigned char*)malloc(datasize);
>  [datastream getBytes:databuffer range:NSMakeRange(positionCounter, 
> datasize)]; // Packet content
> 
> 
> On May 26, 2014, at 3:44 PM, Pax <45rpmli...@googlemail.com> wrote:
> 
>> Apologies - the obvious important detail, and I missed it out entirely.  I 
>> have tried both of the following with the same result:
>> 
>>  unsigned char* databuffer = (unsigned char*)malloc(datasize);
>>  [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
>> datasize)]; // Packet content
>> 
>> and 
>> 
>>  unsigned char* bytes;
>>  [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
>> // Packet content
>> 
>> Either way, I get the same result.
>> 
>> 
>> 
>> On 26 May 2014, at 14:16, Uli Kusterer  wrote:
>> 
>>> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
 This is my snippet of code:
 [datastream getBytes:&bytes 
 range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
 positionCounter+= datasize;
>>> 
>>> What is bytes declared as, and what do you initialize it to?
>>> 
>>> Cheers,
>>> -- Uli Kusterer
>>> “The Witnesses of TeachText are everywhere...”
>>> http://zathras.de
>>> 
>> 
>> ___
>> 
>> 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/mcguffogl%40gmail.com
>> 
>> This email sent to mcguff...@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: EXC_BAD_ACCESS in NSData

[Sandy McGuffog]

Well,

I find your code to be a bit confusing, but I’d say that both of those are 
wrong. I think that what you need is:

  unsigned char* databuffer = (unsigned char*)malloc(datasize);
  [datastream getBytes:databuffer range:NSMakeRange(positionCounter, 
datasize)]; // Packet content


On May 26, 2014, at 3:44 PM, Pax <45rpmli...@googlemail.com> wrote:

> Apologies - the obvious important detail, and I missed it out entirely.  I 
> have tried both of the following with the same result:
> 
>   unsigned char* databuffer = (unsigned char*)malloc(datasize);
>   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
> datasize)]; // Packet content
> 
> and 
> 
>   unsigned char* bytes;
>   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
> // Packet content
> 
> Either way, I get the same result.
> 
> 
> 
> On 26 May 2014, at 14:16, Uli Kusterer  wrote:
> 
>> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
>>> This is my snippet of code:
>>>  [datastream getBytes:&bytes 
>>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>>>  positionCounter+= datasize;
>> 
>> What is bytes declared as, and what do you initialize it to?
>> 
>> Cheers,
>> -- Uli Kusterer
>> “The Witnesses of TeachText are everywhere...”
>> http://zathras.de
>> 
> 
> ___
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@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: EXC_BAD_ACCESS in NSData

[Pax]

Apologies - the obvious important detail, and I missed it out entirely.  I have 
tried both of the following with the same result:

   unsigned char* databuffer = (unsigned char*)malloc(datasize);
   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
datasize)]; // Packet content

and 

   unsigned char* bytes;
   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
// Packet content

Either way, I get the same result.



On 26 May 2014, at 14:16, Uli Kusterer  wrote:

> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
>> This is my snippet of code:
>>   [datastream getBytes:&bytes 
>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>>   positionCounter+= datasize;
> 
> What is bytes declared as, and what do you initialize it to?
> 
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
> 

___

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: EXC_BAD_ACCESS in NSData

[Pax]

Apologies - the obvious important detail, and I missed it out entirely.  I have 
tried both of the following with the same result:

   unsigned char* databuffer = (unsigned char*)malloc(datasize);
   [datastream getBytes:&databuffer range:NSMakeRange(positionCounter, 
datasize)]; // Packet content

and 

   unsigned char* bytes;
   [datastream getBytes:&bytes range:NSMakeRange(positionCounter, datasize)]; 
// Packet content

Either way, I get the same result.



On 26 May 2014, at 14:16, Uli Kusterer  wrote:

> On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
>> This is my snippet of code:
>>   [datastream getBytes:&bytes 
>> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>>   positionCounter+= datasize;
> 
> What is bytes declared as, and what do you initialize it to?
> 
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
> 

___

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: EXC_BAD_ACCESS in NSData

[Uli Kusterer]

On 26 May 2014, at 06:02, Pax <45rpmli...@googlemail.com> wrote:
> This is my snippet of code:
>[datastream getBytes:&bytes 
> range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
>positionCounter+= datasize;

What is bytes declared as, and what do you initialize it to?

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

EXC_BAD_ACCESS in NSData

[Pax]

I'm utterly perplexed by this problem because I thought that I'd been so 
careful in ensuring that my data can be read safely with no problems.

This is my snippet of code:
[datastream getBytes:&bytes 
range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
positionCounter+= datasize;

datasize = (unsigned int)bytes; //This is the length of the 
data indicated in the data structure from the capture.
if (positionCounter+datasize>[datastream length])
{
NSLog(@"Error - Bad size in datastream.");
datasize = [datastream length]-positionCounter-1; //the 
minus one was just put there to ensure that we really are going to read a 
little less data than we have available.

NSLog(@"length %lu, position %lu, datasize %lu, 
pos+size %lu",[datastream 
length],positionCounter,datasize,positionCounter+datasize); // the result of 
this is length 18591, position 2974, datasize 15616, pos+size 18590
}
[datastream getBytes:&bytes 
range:NSMakeRange(positionCounter, datasize)]; // Packet content

When this gets run, I get EXC_BAD_ACCESS code = 2 here.  I'm demonstrably 
reading less data than the file contains, and I've been able to read through 
the file successfully up to this point.  Please could someone suggest to me 
what might be going wrong here?







___

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

EXC_BAD_ACCESS in NSData

[Pax]

I'm utterly perplexed by this problem because I thought that I'd been so 
careful in ensuring that my data can be read safely with no problems.

This is my snippet of code:
[datastream getBytes:&bytes 
range:NSMakeRange(positionCounter, datasize)]; // Length of packet content
positionCounter+= datasize;

datasize = (unsigned int)bytes; //This is the length of the 
data indicated in the data structure from the capture.
if (positionCounter+datasize>[datastream length])
{
NSLog(@"Error - Bad size in datastream.");
datasize = [datastream length]-positionCounter-1; //the 
minus one was just put there to ensure that we really are going to read a 
little less data than we have available.

NSLog(@"length %lu, position %lu, datasize %lu, 
pos+size %lu",[datastream 
length],positionCounter,datasize,positionCounter+datasize); // the result of 
this is length 18591, position 2974, datasize 15616, pos+size 18590
}
[datastream getBytes:&bytes 
range:NSMakeRange(positionCounter, datasize)]; // Packet content

When this gets run, I get EXC_BAD_ACCESS code = 2 here.  I'm demonstrably 
reading less data than the file contains, and I've been able to read through 
the file successfully up to this point.  Please could someone suggest to me 
what might be going wrong here?







___

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

EXC_BAD_ACCESS signal in Core Data app on Lion 10.7.4

[Ken Victor]

i’m getting an EXC_BAD_ACCESS crash in my app when it runs under lion 10.7.4. 
the app runs fine on 10.6.8. the app is built with xCode 3.2.6 on lion, using 
the 10.6 sdk and targeting 10.6. 

this is 100% repeatable. when the user executes a menu item, i execute a bunch 
of code that includes several changes to several core data objects. in this 
processing, i also defer some execution via -performSelectorOnMainThread 
(without waiting for completion). a few, but not all, of my deferred requests 
have executed and this crash happens when one of the deferred requests finishes.

i normally run my debug environment with zombies enabled and i’m not getting 
any hits. and fwiw, i’m testing using a 2006 MacPro with 9GB memory.

can anyone offer me suggestions or pointers to documentation to help me find 
this? or can anyone explain to me what might be going on that could cause this 
crash? 

thanx,
ken


#0  0x7fff891d5fd0 in -[NSManagedObject(_NSInternalMethods) 
_newSnapshotForUndo__]
#1  0x7fff891b60ea in -[NSManagedObjectContext(_NSInternalChangeProcessing) 
_registerUndoForOperation:withObjects:withExtraArguments:]
#2  0x7fff891b218e in -[NSManagedObjectContext(_NSInternalChangeProcessing) 
_processRecentChanges:]
#3  0x7fff891d745e in 
-[NSManagedObjectContext(_NSInternalNotificationHandling) 
_processEndOfEventNotification:]
#4  0x7fff86450d0e in __-[NSNotificationCenter 
addObserver:selector:name:object:]_block_invoke_1
#5  0x7fff88fe77ba in _CFXNotificationPost
#6  0x7fff8643cfc3 in -[NSNotificationCenter 
postNotificationName:object:userInfo:]
#7  0x7fff865b7e00 in -[NSUndoManager _postCheckpointNotification]
#8  0x7fff865b7a07 in -[NSUndoManager _endUndoGroupRemovingIfEmpty:]
#9  0x7fff891b66a4 in -[NSManagedObjectContext(_NSInternalChangeProcessing) 
_updateUndoTransactionForThisEvent:withDeletions:withUpdates:]
#10 0x7fff891b220e in -[NSManagedObjectContext(_NSInternalChangeProcessing) 
_processRecentChanges:]
#11 0x7fff8918ab87 in _performRunLoopAction
#12 0x7fff88ffe8e7 in 
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
#13 0x7fff88ffe846 in __CFRunLoopDoObservers
#14 0x7fff88fd34a2 in CFRunLoopRunSpecific
#15 0x7fff8b5d64d3 in RunCurrentEventLoopInMode
#16 0x7fff8b5dd6d3 in ReceiveNextEventCommon
#17 0x7fff8b5dd60e in BlockUntilNextEventMatchingListInMode
#18 0x7fff84260e31 in _DPSNextEvent
#19 0x7fff84260735 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#20 0x7fff8425d071 in -[NSApplication run]
#21 0x7fff844d9244 in NSApplicationMain
#22 0x1000165d9 in main at main.m:13
#23 0x116d8 in start


___

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 debugging EXC_BAD_ACCESS

[Rick Mann]

Thanks, Mike, I figured it out. Xcode was hiding most of the stack, including 
the bit that had the answer. I didn't realize this.

On Apr 5, 2012, at 10:25 , Mike Abdullah wrote:

> What's the backtrace of the crash?
> 
> How's your +addOperationOnMainQueueWithBlock: method implemented?
> 
> On 5 Apr 2012, at 01:09, Rick Mann wrote:
> 
>> This is odd. I have an app that downloads locations from a web service, and 
>> creates NSManagedObejct (subclass: Location) for them. It's been working 
>> fine on simulator and device. Suddenly, I get a consistent EXC_BAD_ACCESS on 
>> device and simulator every time I create a new location (existing locations 
>> in the store work fine.
>> 
>> Here's the code snippet:
>> 
>>   [NSOperationQueue  addOperationOnMainQueueWithBlock:
>>   ^{
>>   for (NSDictionary* locD in locs)
>>   {
>>   NSNumber* woeID = [locD valueForKey: @"woeid"];
>>   Location* loc = [Location locationWithId: woeID inMOC: inMOC];
>> 
>>   loc.temp = [locD valueForKey: @"temp"];
>>   NSString* s = [locD valueForKey: @"photoURI"];
>>   loc.photoURI = s;
>> 
>> The line that gets the error is the last line. Thread 1: EXC_BAD_ACCESS 
>> (code=1, address=0x8).
>> 
>> po loc and po s both work. photoURI is a simple dynamic property on 
>> Location, type NSString. The other property, temp, is NSNumber, and always 
>> executes fine.
>> 
>> Any ideas? I don't really even know what to check for. ARC, 5.1, Xc4.3.2
>> 
>> Thanks!
>> 
>> -- 
>> Rick
>> 
>> 
>> 
>> 
>> ___
>> 
>> 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/cocoadev%40mikeabdullah.net
>> 
>> This email sent to cocoa...@mikeabdullah.net
> 


___

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 debugging EXC_BAD_ACCESS

[Mike Abdullah]

What's the backtrace of the crash?

How's your +addOperationOnMainQueueWithBlock: method implemented?

On 5 Apr 2012, at 01:09, Rick Mann wrote:

> This is odd. I have an app that downloads locations from a web service, and 
> creates NSManagedObejct (subclass: Location) for them. It's been working fine 
> on simulator and device. Suddenly, I get a consistent EXC_BAD_ACCESS on 
> device and simulator every time I create a new location (existing locations 
> in the store work fine.
> 
> Here's the code snippet:
> 
>[NSOperationQueue  addOperationOnMainQueueWithBlock:
>^{
>for (NSDictionary* locD in locs)
>{
>NSNumber* woeID = [locD valueForKey: @"woeid"];
>Location* loc = [Location locationWithId: woeID inMOC: inMOC];
> 
>loc.temp = [locD valueForKey: @"temp"];
>NSString* s = [locD valueForKey: @"photoURI"];
>    loc.photoURI = s;
> 
> The line that gets the error is the last line. Thread 1: EXC_BAD_ACCESS 
> (code=1, address=0x8).
> 
> po loc and po s both work. photoURI is a simple dynamic property on Location, 
> type NSString. The other property, temp, is NSNumber, and always executes 
> fine.
> 
> Any ideas? I don't really even know what to check for. ARC, 5.1, Xc4.3.2
> 
> Thanks!
> 
> -- 
> Rick
> 
> 
> 
> 
> ___
> 
> 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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.net


___

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

Help debugging EXC_BAD_ACCESS

[Rick Mann]

This is odd. I have an app that downloads locations from a web service, and 
creates NSManagedObejct (subclass: Location) for them. It's been working fine 
on simulator and device. Suddenly, I get a consistent EXC_BAD_ACCESS on device 
and simulator every time I create a new location (existing locations in the 
store work fine.

Here's the code snippet:

[NSOperationQueue  addOperationOnMainQueueWithBlock:
^{
for (NSDictionary* locD in locs)
{
NSNumber* woeID = [locD valueForKey: @"woeid"];
Location* loc = [Location locationWithId: woeID inMOC: inMOC];

loc.temp = [locD valueForKey: @"temp"];
NSString* s = [locD valueForKey: @"photoURI"];
loc.photoURI = s;

The line that gets the error is the last line. Thread 1: EXC_BAD_ACCESS 
(code=1, address=0x8).

po loc and po s both work. photoURI is a simple dynamic property on Location, 
type NSString. The other property, temp, is NSNumber, and always executes fine.

Any ideas? I don't really even know what to check for. ARC, 5.1, Xc4.3.2

Thanks!

-- 
Rick




___

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: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Greg Parker]

On Feb 20, 2012, at 10:16 AM, Matt Neuburg  wrote:
> On Fri, 17 Feb 2012 16:06:01 -0800, Greg Parker  said:
>> No. objc_msgSend() also reads from the class's method cache and method list. 
>> It's possible for the receiver object to be valid, but still crash because 
>> of a memory smasher that hit the method cache or method list
> 
> It's also possible for the receiver object to be valid but the wrong object. 
> I remember in my early Cocoa programming days I mismanaged the memory for an 
> NSString object and was mystified when *another NSString object took its 
> place*. I believe NSZombie would have tracked that down by occupying the slot 
> pointed to by the variable and not letting some other string slip into it. In 
> other words, believe in zombies, not in your intuitions about how everything 
> looks okay. :) m.

Having a prematurely-deallocated object replaced by a new object of the same 
type can lead to all sorts of exciting bugs, but a crash in objc_msgSend() 
itself is not one of them. (And yes, NSZombie is good at catching such cases. 
The dead object's address will not be re-used, at least not any time soon.)


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Sean McBride]

On Fri, 17 Feb 2012 16:06:01 -0800, Greg Parker said:

>Those of us who wrote objc_msgSend() can sometimes track down the
>problem by finding which data structure was damaged and examining the
>bad data. Everyone else should try Zombies, Guard Malloc, and Malloc Scribble.

And valgrind... if it works reasonably these days...

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Matt Neuburg]

On Fri, 17 Feb 2012 16:06:01 -0800, Greg Parker  said:
>No. objc_msgSend() also reads from the class's method cache and method list. 
>It's possible for the receiver object to be valid, but still crash because of 
>a memory smasher that hit the method cache or method list

It's also possible for the receiver object to be valid but the wrong object. I 
remember in my early Cocoa programming days I mismanaged the memory for an 
NSString object and was mystified when *another NSString object took its 
place*. I believe NSZombie would have tracked that down by occupying the slot 
pointed to by the variable and not letting some other string slip into it. In 
other words, believe in zombies, not in your intuitions about how everything 
looks okay. :) m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Greg Parker]

On Feb 17, 2012, at 2:02 PM, Jerry Krinock wrote:
> On 2012 Feb 17, at 09:54, Kyle Sluder wrote:
>> All that means is that the storage for the object hasn't been overwritten 
>> yet.
> 
> Thank you, Kyle, and I see what you mean.  But also my tests show that the 
> object is still able to respond to messages, which means that it shouldn't 
> have crashed objc_msgSend.  No?

No. objc_msgSend() also reads from the class's method cache and method list. 
It's possible for the receiver object to be valid, but still crash because of a 
memory smasher that hit the method cache or method list. If those data 
structures are damaged in the right way then some messages will succeed and 
other messages will crash, which is consistent with your ability to send other 
messages to the object.

Those of us who wrote objc_msgSend() can sometimes track down the problem by 
finding which data structure was damaged and examining the bad data. Everyone 
else should try Zombies, Guard Malloc, and Malloc Scribble.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Jerry Krinock]

On 2012 Feb 17, at 09:54, Kyle Sluder wrote:

> All that means is that the storage for the object hasn't been overwritten yet.

Thank you, Kyle, and I see what you mean.  But also my tests show that the 
object is still able to respond to messages, which means that it shouldn't have 
crashed objc_msgSend.  No?

> What does NSZombieEnabled say?

Well, as usual, this crash happened when NSZombieEnabled was not active.  I've 
scripted Xcode and the crash conditions, and my script is now testing 
repeatedly with NSZombieEnabled and friends active.

As to my implied question: Can anything other than a deallocced receiver or 
deallocced parameter cause a crash in objc_msgSend?  I re-read Greg Parker's 
article on this topic…

http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html

I would paraphrase Greg's answer as "Usually it's due to a deallocced object, 
but not always, and in the latter case you're in deep doodoo."  I'm hoping to 
get another crash with zombies on, while I think about the code.



___

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: How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Kyle Sluder]

On Fri, Feb 17, 2012 at 8:53 AM, Jerry Krinock  wrote:
>
> Both the receiver (a window controller) and the method's parameter (a timer) 
> both seem to be good, live, valid objects…
>
> (gdb) po 0xcdbf570
> 
> (gdb) po [0xcdbf570 window]
> 
> (gdb) po 0x9315960
> <__NSCFTimer: 0x9315960>
> (gdb) po [0x9315960 userInfo]
> {
>    agentLabel = "6609802C6B47.000.001.doSoon.36665";
> }

All that means is that the storage for the object hasn't been
overwritten yet. What does NSZombieEnabled say?

--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

How EXC_BAD_ACCESS in objc_msgSend if receiver, parms OK?

[Jerry Krinock]

I got an EXC_BAD_ACCESS in objc_msgSend.  By probing registers in gdb, I am 
able to get the receiver, selector and the single parameter of the offending 
message.

(gdb) po *(int*)($ebp+8)


(gdb) po NSStringFromSelector(*(int*)($ebp+12))
updateAgentActivityNow:

(gdb) po *(int*)($ebp+16)
<__NSCFTimer: 0x9315960>

So it's is a message from Cocoa's timer-firing mechanism, firing the selector 
of a timer.  Given where the program was, this message is expected.

Both the receiver (a window controller) and the method's parameter (a timer) 
both seem to be good, live, valid objects…

(gdb) po 0xcdbf570

(gdb) po [0xcdbf570 window]

(gdb) po 0x9315960
<__NSCFTimer: 0x9315960>
(gdb) po [0x9315960 userInfo]
{
agentLabel = "6609802C6B47.000.001.doSoon.36665";
}

I "manually" sent most of the messages in the offending method, and got mostly 
expected results [1].  One message was too hairy to send manually.

So how could there have been EXC_BAD_ACCESS?  In my experience, I think that 
I've seen such inexplicable crashes caused by something *really* bad in the 
offending method, such as wrong parameters in a format string.  I think that 
sometimes gdb gets so upset that it can't show you the top of the call stack.  
Is that true?

If I try to manually send the crashed message using gdb's 'call' command, I 
also get EXC_BAD_ACCESS…

(gdb) call [0xcdbf570 updateAgentActivityNow:0x9315960]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x63610002
0x9985cd4b in objc_msgSend ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (objc_msgSend) will be 
abandoned.

What could be going on here?

The crash occurs on the main thread.

I would like to discount this crash as an artifact of my using Xcode 3 under 
Mac OS 10.7, but unfortunately the offending method is one that I recently 
added to a large project.  Not a likely coincidence.

Thanks,

Jerry Krinock

Here is the call stack:

#0  0x9985cd47 in objc_msgSend
#1  0x003053cc in maxInt.32934
#2  0x9b850bdf in __NSFireTimer
#3  0x92511656 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
#4  0x92510fe7 in __CFRunLoopDoTimer
#5  0x924eff70 in __CFRunLoopRun
#6  0x924ef47c in CFRunLoopRunSpecific
#7  0x924ef328 in CFRunLoopRunInMode
#8  0x91e5617f in RunCurrentEventLoopInMode
#9  0x91e5d4e7 in ReceiveNextEventCommon
#10 0x91e5d356 in BlockUntilNextEventMatchingListInMode
#11 0x9bb07a9c in _DPSNextEvent
#12 0x9bb07306 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#13 0x9bb03675 in -[NSApplication run]
#14 0x9bd97261 in NSApplicationMain
#15 0x1e15 in main at MainApp-Main.m:49


[1] Here is the offending method, with comments added to show the results of my 
"manually" running the lines.

- (void)updateAgentActivityNow:(NSTimer*)timer {
// I have subclassed NSApp so I can switch off "dock bouncing".  See below 
[2].
[NSApp setBeQuiet:YES] ;
// When I tried to send the above message manually, I got an inexplicable 
result:
//(gdb) call [NSApp setBeQuiet:1]
//Value can't be converted to integer.
// I don't know what that means.

Bkmslf* bkmslf = (Bkmslf*)[self document] ;
// Sending the above message "manually" returns the live document as 
expected.
BkmxAgentActivity oldState = [self agentActivityFilteredState] ;
BkmxAgentActivity newState = [self agentActivityLastInputState] ;
[self setAgentActivityFilteredState:newState] ;
// Sending the above three messages manually works OK.
// I can even set and then get those two attributes.

if (oldState != BkmxAgentActivityNone) {
// Based on value of old state, this branch would have executed.
[self dismissAgentActivityAlertSheet] ;
// However I don't think there's any problem here.  See below [3].
}

NSString* irregularAgentLabel = [[timer userInfo] 
objectForKey:constKeyAgent] ;
// Sending the above message manually gives the expected result

if (newState == BkmxAgentActivityStaged) {
// Based on value of newState, this branch *would* be executed.
if ([self shouldPerformNow]) {
   // Based on value of shouldPerformNow, this branch *would* be 
executed.
Agent* agent ;
Trigger* trigger ;
// I didn't try to send this message since I don't know the values
// of the two return-by-reference parameters.
[self whyForAgentLabel:irregularAgentLabel
   agent_p:&agent
 trigger_p:&trigger] ;

 

Re: Return causes EXC_BAD_ACCESS

[Scott Ribe]

On Jul 31, 2011, at 8:27 AM, Scott Ribe wrote:

> No, fork copies the entire address space when it is called, but vfork works 
> as he described. In neither case will modifications to memory by one process 
> by visible by the other.

Oh, hogwash. Of course copy-on-write is a common optimization to fork. And with 
vfork modifications can be visible to the other process, but the calling 
process is suspended until the new process exits or calls exec, so it's not 
useful for interprocess communication, just a side effect available very 
briefly.

Sorry for the prior noise.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Scott Ribe]

On Jul 31, 2011, at 1:59 AM, vincent habchi wrote:

> Thanks for these precisions. Actually, you’re right with fork (2), but vfork 
> (2), AFAIK, does not copy anything; note that I’m aware that vfork usually is 
> meant to be immediately followed by exec (3).

No, fork copies the entire address space when it is called, but vfork works as 
he described. In neither case will modifications to memory by one process by 
visible by the other.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[vincent habchi]

Le 31 juil. 2011 à 09:27, Ron Hunsinger a écrit :

> When a process forks, the child and parent get different virtual memory maps 
> that, for the time being, happen to point to the same physical memory pages. 
> The sharing is an implementation detail, for optimization. Conceptually, the 
> parent's memory is copied into the child's memory space, so that if one of 
> the processes modifies the "shared" memory, the other process does not see 
> the change. The implementation, under the hood, does copy-on-write so that 
> the cost of that copying can be deferred until needed. Since fork is usually 
> followed by exec in the child, the copying usually never takes place, so it's 
> a particularly good optimization. Don't be misled into thinking that just 
> because the copying is deferred that the parent and child are actually 
> sharing a single virtual memory space.

Thanks for these precisions. Actually, you’re right with fork (2), but vfork 
(2), AFAIK, does not copy anything; note that I’m aware that vfork usually is 
meant to be immediately followed by exec (3).

> The other methods you mention of sharing memory are by special arrangement, 
> and rarely used (although extremely useful when they are).

I agree also. My point was to mitigate the statement that processes cannot 
share common memory. Of course, as you mentioned, in normal operation they 
don’t: That’s, after all, the whole point of the MMU, applications live in a 
memory sandbox. As far as I remember, wasn’t it D. Ritchie who related that, 
when developing on old PDP11/70, it was customary to yell "a.out !" when you 
were about to launch a program, because it gave others time to save their work 
before a possible general crash or data corruption? 

Vincent


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Ron Hunsinger]

On Jul 31, 2011, at 12:27 AM, Ron Hunsinger wrote:

> The point vincent was making was ...

Sorry for the misattribution. I meant "The point Graham Cox and Scott Ribe were 
making was ...".

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Ron Hunsinger]

On Jul 30, 2011, at 11:39 PM, vincent habchi wrote:

>> Memory is "virtual", the addresses you appear to be working with are not 
>> real (i.e. they don't refer to the real address of the physical RAM 
>> underneath). Instead, a bit of hardware translates these to the real 
>> addresses as needed at some level far below the perception of your program. 
>> You cannot access the virtual address space of any other process other than 
>> your own.
> 
> That is, of course, not true. When a process forks, the child and the parent, 
> though being two separate processes, still share the same virtual memory map 
> (at least until the child calls exec (3)). And you can arrange to share pages 
> of memory in different processes via, e.g, shmat (2), at the Unix level. 
> That's how most databases (e.g. PostGreSQL) work, inter alia.

You're quibbling, and not exactly with exactitude.

When a process forks, the child and parent get different virtual memory maps 
that, for the time being, happen to point to the same physical memory pages. 
The sharing is an implementation detail, for optimization. Conceptually, the 
parent's memory is copied into the child's memory space, so that if one of the 
processes modifies the "shared" memory, the other process does not see the 
change. The implementation, under the hood, does copy-on-write so that the cost 
of that copying can be deferred until needed. Since fork is usually followed by 
exec in the child, the copying usually never takes place, so it's a 
particularly good optimization. Don't be misled into thinking that just because 
the copying is deferred that the parent and child are actually sharing a single 
virtual memory space.

The other methods you mention of sharing memory are by special arrangement, and 
rarely used (although extremely useful when they are).

The point vincent was making was to correct the OP's belief that a random 
pointer (0x18c95b0 was the example mentioned) pointed to some memory somewhere, 
and that the EXC_BAD_ACCESS exception was raised if that memory happened to 
belong to some other process.

The truth is, each process has its own virtual memory map, and 0x18c95b0 may 
point to different physical addresses, or to nowhere, depending on which of 
those memory maps you look it up in. But a process does not have the 
opportunity to try looking it up in any map but its own. The exception is 
raised if the current process' memory map doesn't map it to anywhere. (It could 
also be raised if the pointer is being looked up for write access, but the 
current memory map maps it to a read-only location.)

That is, it's not "look up the address, and see who it belongs to" but "look up 
the address in my space, and see if it exists there".

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[vincent habchi]

> Memory is "virtual", the addresses you appear to be working with are not real 
> (i.e. they don't refer to the real address of the physical RAM underneath). 
> Instead, a bit of hardware translates these to the real addresses as needed 
> at some level far below the perception of your program. You cannot access the 
> virtual address space of any other process other than your own.

That is, of course, not true. When a process forks, the child and the parent, 
though being two separate processes, still share the same virtual memory map 
(at least until the child calls exec (3)). And you can arrange to share pages 
of memory in different processes via, e.g, shmat (2), at the Unix level. That's 
how most databases (e.g. PostGreSQL) work, inter alia.

Vincent___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Graham Cox]

On 29/07/2011, at 7:33 AM, Mr. Gecko wrote:

> From my understanding, this should happen when you, for an example, try to 
> access the pointer 0x18c95b0 whenever that belongs to another process.


No.

Memory is "virtual", the addresses you appear to be working with are not real 
(i.e. they don't refer to the real address of the physical RAM underneath). 
Instead, a bit of hardware translates these to the real addresses as needed at 
some level far below the perception of your program. You cannot access the 
virtual address space of any other process other than your own.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Jens Alfke]

On Jul 28, 2011, at 3:00 PM, Kyle Sluder wrote:

> I'm not sure what your motivation is for calling [self release] here,
> but no code should be doing this.

I disagree. There are a couple of reasons to call this:

- It’s pat of the failure path for -init methods. Before returning nil you need 
to call [self release] to avoid leaking.

- An object that performs some asynchronous task may want to retain itself when 
starting the task, and release itself when done, to make sure it won’t get 
dealloced before the task finishes.


Mr. Gecko wrote:
> I am still looking to an link to explanation in detail as to why this happens

If ‘foundCookieJar’ is an instance variable, than any time you refer to it in a 
method, the compiler actually implements it as “self->foundCookieJar”. From 
that, it should be pretty clear that if you set self to nil, the next reference 
to ‘self->foundCookieJar’ is a nil pointer access that’s going to crash.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Scott Ribe]

On Jul 28, 2011, at 3:33 PM, Mr. Gecko wrote:

> From my understanding, this should happen when you, for an example, try to 
> access the pointer 0x18c95b0 whenever that belongs to another process. 
> However, I also thought that the Mac has a copy of memory space for each 
> process and therefore should not be able to access memory that it doesn't own 
> unless the core os does so.

No, not even close. It happens when you access a memory address that has not 
been mapped into your process' memory space. I've given you plenty of terms to 
google; go for it.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Dave DeLong]

Well, let's think about it.  "Instance variables" are only accessible as long 
as you have an instance, right?  You can't have an instance variable without an 
instance.  So if you set "self" to nil... then you no longer have an instance.  
Thus, you cannot access self's instance variables, because there is no self.

Sorry I don't have a doc link for you; perhaps someone more well-versed with 
the documentation search tools than I can find something relevant.  :)

Dave

On Jul 28, 2011, at 2:45 PM, Mr. Gecko wrote:

> That makes lots of sense, never even expected that to happen. Adding a local 
> variable and setting it to the value before releasing it and returning that 
> variable fixes the issue. I am still looking to an link to explanation in 
> detail as to why this happens. If it's as I said, then I do not think I need 
> it.
> 
> On Jul 28, 2011, at 4:35 PM, Dave DeLong wrote:
> 
>> It kind of looks like foundCookieJar is an ivar, which means that "return 
>> foundCookieJar" is really going to be "return self->foundCookieJar".  Since 
>> you set "self" to "nil", you're trying to dereference a NULL pointer, which 
>> is a great way to crash your app.
>> 
>> HTH,
>> 
>> Dave

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Kyle Sluder]

On Thu, Jul 28, 2011 at 2:45 PM, Mr. Gecko  wrote:
> That makes lots of sense, never even expected that to happen. Adding a local 
> variable and setting it to the value before releasing it and returning that 
> variable fixes the issue. I am still looking to an link to explanation in 
> detail as to why this happens. If it's as I said, then I do not think I need 
> it.

There's a very strong but unwritten expectation that self remains
valid for the entirety of a method implementation, except possibly in
-init.

ARC enforces this restriction: self is const in all non-init methods.

I'm not sure what your motivation is for calling [self release] here,
but no code should be doing this.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Mr. Gecko]

That makes lots of sense, never even expected that to happen. Adding a local 
variable and setting it to the value before releasing it and returning that 
variable fixes the issue. I am still looking to an link to explanation in 
detail as to why this happens. If it's as I said, then I do not think I need it.

On Jul 28, 2011, at 4:35 PM, Dave DeLong wrote:

> It kind of looks like foundCookieJar is an ivar, which means that "return 
> foundCookieJar" is really going to be "return self->foundCookieJar".  Since 
> you set "self" to "nil", you're trying to dereference a NULL pointer, which 
> is a great way to crash your app.
> 
> HTH,
> 
> Dave
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Return causes EXC_BAD_ACCESS

[Dave DeLong]

It kind of looks like foundCookieJar is an ivar, which means that "return 
foundCookieJar" is really going to be "return self->foundCookieJar".  Since you 
set "self" to "nil", you're trying to dereference a NULL pointer, which is a 
great way to crash your app.

HTH,

Dave

On Jul 28, 2011, at 2:33 PM, Mr. Gecko wrote:

> I am unable to find out as to why I am receiving this problem, I can verify 
> other parts of the code before it gets to the return and that the object I am 
> returning does in-fact work as I am able to NSLog it and see the description 
> of it. The basic idea of this code is to notify other objects to see if one 
> exists with the same path and if it does, it will tell the object I am using 
> to check where it is at by setFoundCookieJar:self. It seems to work, as I can 
> see the value when logging it. This one problem is stopping the code I wrote 
> from being usable.
> 
> If someone can explain why this is happening and give me a link to 
> explanation on this signal and why it occurs as I have and a friend of mine 
> has seen it in weird areas that seems like it should work from an understand 
> of the code and playing around seems like it will work by logging out 
> information. From my understanding, this should happen when you, for an 
> example, try to access the pointer 0x18c95b0 whenever that belongs to another 
> process. However, I also thought that the Mac has a copy of memory space for 
> each process and therefore should not be able to access memory that it 
> doesn't own unless the core os does so.
> 
> [notificationCenter postNotificationName:MGMCookieJarExists object:self 
> userInfo:[NSDictionary dictionaryWithObject:cookiesPath 
> forKey:MGMCookieJarKey]];
> if (foundCookieJar!=nil) {
>   [self release];
>   self = nil;
>   return foundCookieJar;
> }
> 
> Thanks for any help on this issue,
> Mr. Gecko___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/davedelong%40me.com
> 
> This email sent to davedel...@me.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Return causes EXC_BAD_ACCESS

[Mr. Gecko]

I am unable to find out as to why I am receiving this problem, I can verify 
other parts of the code before it gets to the return and that the object I am 
returning does in-fact work as I am able to NSLog it and see the description of 
it. The basic idea of this code is to notify other objects to see if one exists 
with the same path and if it does, it will tell the object I am using to check 
where it is at by setFoundCookieJar:self. It seems to work, as I can see the 
value when logging it. This one problem is stopping the code I wrote from being 
usable.

If someone can explain why this is happening and give me a link to explanation 
on this signal and why it occurs as I have and a friend of mine has seen it in 
weird areas that seems like it should work from an understand of the code and 
playing around seems like it will work by logging out information. From my 
understanding, this should happen when you, for an example, try to access the 
pointer 0x18c95b0 whenever that belongs to another process. However, I also 
thought that the Mac has a copy of memory space for each process and therefore 
should not be able to access memory that it doesn't own unless the core os does 
so.

[notificationCenter postNotificationName:MGMCookieJarExists object:self 
userInfo:[NSDictionary dictionaryWithObject:cookiesPath 
forKey:MGMCookieJarKey]];
if (foundCookieJar!=nil) {
[self release];
self = nil;
return foundCookieJar;
}

Thanks for any help on this issue,
Mr. Gecko___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: EXC_BAD_ACCESS in NSApplicationMain

[Ayers, Joseph]

That certainly made a difference. It's choking on a nib

#0 0x97876d54 in objc_msgSend ()
#1 0x96e6a960 in CFHash ()
#2 0x96e709c0 in __CFSetStandardHashKey ()
#3 0x96e740c2 in CFBasicHashAddValue ()
#4 0x96e8b2d4 in CFSetAddValue ()
#5 0x96ee3395 in -[__NSCFSet addObject:] ()
#6 0x94a595b1 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] ()
#7 0x94a4f679 in loadNib ()
#8 0x94a4ea60 in +[NSBundle(NSNibLoading) 
_loadNibFile:nameTable:withZone:ownerBundle:] ()
#9 0x94a4e96a in +[NSBundle(NSNibLoading) 
loadNibFile:externalNameTable:withZone:] ()
#10 0x94a4e89e in +[NSBundle(NSNibLoading) loadNibNamed:owner:] ()
#11 0x94cd58f3 in NSApplicationMain ()
#12 0x00010d64 in main at /Users/lobster/Desktop/Roboplasm/main.m:14

Off to ponder that.

ja


On Jul 24, 2011, at 8:04 PM, Quincey Morris wrote:

On Jul 24, 2011, at 15:50, Ayers, Joseph wrote:

In XCode 4.1. and Lion,, compiling for OS X 10.6, My application is crashing in 
main.m. Specifically it exhibits EXC_BAD_ACCESS errors in main.m, 
NSApplicationMain and obj_msgSend on disassembly. I've got symbolic breakpoints 
at:  “objc_exception_throw” and “[NSException raise]“.

Any idea how to get beyond this?

Your application didn't really crash in NSApplicationMain, but Xcode has 
collapsed the backtrace so that you can't see the place it stopped.  This is a 
usability issue in Xcode 4.

With the Debugger tab of the Navigator pane visible, look at the "level of 
detail" slider at the bottom of the pane, and drag it all the way to right-hand 
end.



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: EXC_BAD_ACCESS in NSApplicationMain

[Quincey Morris]

On Jul 24, 2011, at 15:50, Ayers, Joseph wrote:

> In XCode 4.1. and Lion,, compiling for OS X 10.6, My application is crashing 
> in main.m. Specifically it exhibits EXC_BAD_ACCESS errors in main.m, 
> NSApplicationMain and obj_msgSend on disassembly. I've got symbolic 
> breakpoints at:  “objc_exception_throw” and “[NSException raise]“.
> 
> Any idea how to get beyond this?

Your application didn't really crash in NSApplicationMain, but Xcode has 
collapsed the backtrace so that you can't see the place it stopped.  This is a 
usability issue in Xcode 4. 

With the Debugger tab of the Navigator pane visible, look at the "level of 
detail" slider at the bottom of the pane, and drag it all the way to right-hand 
end.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: EXC_BAD_ACCESS in NSApplicationMain

[Tito Ciuro]

Hi Joseph,

If you type 'bt' in GDB, do you see something like this by any chance?:

> #74 0x7fff8686f312 in -[NSIBObjectData initWithCoder:] ()
> #75 0x7fff827fbe73 in _decodeObjectBinary ()
> #76 0x7fff827fb2ed in _decodeObject ()
> #77 0x7fff8686ea41 in loadNib ()
> #78 0x7fff8686dfa1 in +[NSBundle(NSNibLoading) 
> _loadNibFile:nameTable:withZone:ownerBundle:] ()
> #79 0x7fff8686ddd9 in +[NSBundle(NSNibLoading) loadNibNamed:owner:] ()
> #80 0x7fff8686b35b in NSApplicationMain ()
> #81 0x000100011370 in main (argc=1, argv=0x7fff5fbff5c0) at main.m:13
> (gdb)

I started seeing this in Xcode 4.1 and 4.2 too.

-- Tito

On Jul 24, 2011, at 7:50 PM, Ayers, Joseph wrote:

> In XCode 4.1. and Lion,, compiling for OS X 10.6, My application is crashing 
> in main.m. Specifically it exhibits EXC_BAD_ACCESS errors in main.m, 
> NSApplicationMain and obj_msgSend on disassembly. I've got symbolic 
> breakpoints at:  “objc_exception_throw” and “[NSException raise]“.
> 
> Any idea how to get beyond this?
> 
> Thanks,
> Joseph
> 
> main.m
> 
> #import 
> 
> int main(int argc, char *argv[])
> {
>return NSApplicationMain(argc, (const char **) argv);   < Thread 1 
> EXC_BAD_ACCESS (code = 1, address = 0x553838b0)
> }
> 
> Errors
> 
> in  objc_msgSend_disassembly_0x97876d54.s
> 
> The offending line is
> 
> 0x97876d54:  movl   8(%edi,%edx,4), %eax < Thread 1 EXC_BAD_ACCESS (code = 1,
> 
> in NSApplicationMain_disassembly_0x94cd58f3.s
> 
> The offending line is:
> 
> 0x94cd58f3:  testb  %al, %al < Thread 1 EXC_BAD_ACCESS (code = 1,
> 
> in main.m, the offending line is:
> 
>return NSApplicationMain(argc, (const char **) argv); < Thread 1 
> EXC_BAD_ACCESS (code = 1,
> 
> argc = (int) 1
> argv = (char**) 0xbb18
> 
> 
> 
> Joseph Ayers, Professor
> Department of Biology and
> Marine Science Center
> Northeastern University
> East Point, Nahant, MA 01908
> Phone (781) 581-7370 x309(office), x335(lab)
> Boston: 444 Richards Hall (617) 373-4044
> Cellular (617) 755-7523, FAX: (781) 581-6076
> Google Voice: (781) 346-9589
> eMail: lobs...@neu.edu<mailto:lobs...@neu.edu>
> iPhone: robopl...@gmail.com<mailto:robopl...@gmail.com>
> http://www.neurotechnology.neu.edu/
> http://robobees.seas.harvard.edu/
> http://cyberplasm.net/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/tciuro%40mac.com
> 
> This email sent to tci...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

EXC_BAD_ACCESS in NSApplicationMain

[Ayers, Joseph]

In XCode 4.1. and Lion,, compiling for OS X 10.6, My application is crashing in 
main.m. Specifically it exhibits EXC_BAD_ACCESS errors in main.m, 
NSApplicationMain and obj_msgSend on disassembly. I've got symbolic breakpoints 
at:  “objc_exception_throw” and “[NSException raise]“.

Any idea how to get beyond this?

Thanks,
Joseph

main.m

#import 

int main(int argc, char *argv[])
{
return NSApplicationMain(argc, (const char **) argv);   < Thread 1 
EXC_BAD_ACCESS (code = 1, address = 0x553838b0)
}

Errors

in  objc_msgSend_disassembly_0x97876d54.s

The offending line is

0x97876d54:  movl   8(%edi,%edx,4), %eax < Thread 1 EXC_BAD_ACCESS (code = 1,

in NSApplicationMain_disassembly_0x94cd58f3.s

The offending line is:

0x94cd58f3:  testb  %al, %al < Thread 1 EXC_BAD_ACCESS (code = 1,

in main.m, the offending line is:

return NSApplicationMain(argc, (const char **) argv); < Thread 1 
EXC_BAD_ACCESS (code = 1,

argc = (int) 1
argv = (char**) 0xbb18



Joseph Ayers, Professor
Department of Biology and
Marine Science Center
Northeastern University
East Point, Nahant, MA 01908
Phone (781) 581-7370 x309(office), x335(lab)
Boston: 444 Richards Hall (617) 373-4044
Cellular (617) 755-7523, FAX: (781) 581-6076
Google Voice: (781) 346-9589
eMail: lobs...@neu.edu<mailto:lobs...@neu.edu>
iPhone: robopl...@gmail.com<mailto:robopl...@gmail.com>
http://www.neurotechnology.neu.edu/
http://robobees.seas.harvard.edu/
http://cyberplasm.net/











___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

EXC_BAD_ACCESS searching PDF

[Piero Campanelli]

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Jerry Krinock]

Thanks, all.

Quincey, the three Error Points you defined are great.  Fortunately, in this 
case I have the easy one…

On 2011 May 29, at 13:03, Quincey Morris wrote:
> Error point #2 (super returns nil) is easy. Just return nil.

because one should assume that the superclass will have cleaned up after itself 
before returning nil.

My mistake was to blindly apply Greg Parker's advice in all cases when in fact 
it only applies to Error point #3.

On 2011 May 29, at 13:17, Quincey Morris wrote:

> The significance of calling it a bug is that someone might actually file a 
> bug report, which might result in Apple either allowing nil in the super case 
> or changing the documentation to match the actual behavior. I don't care 
> which is the outcome, but I think one of those things should happen.

Well, it's Bug ID# 9522343 now.  I called it a Documentation bug.

A possible justification for the current situation is that "super is not self". 
 However, there should at least be mention made in "Sending Messages to nil" 
that sending a message to super when self is nil will likely crash.  

I linked Apple to this thread.  With 60 billion in the bank, I figure they can 
afford to give it at least as much thought as you and Ken have, or even easier, 
copy and paste your text into one of their documents.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Quincey Morris]

On May 29, 2011, at 12:57, Ken Thomases wrote:

> But it's important to recognize that there are good arguments on both sides 
> and the design decision involved a tradeoff.  In any case, it doesn't seem to 
> me that that design decision necessarily implies that calling super with a 
> nil self should also be safe.  The two can be considered separately.  In this 
> case, it was actually good that it crashed, since Jerry's code had a bug and 
> it was found earlier than it might otherwise have been.  Put another way, 
> what nice patterns would be enabled if it were safe to message super when 
> self is nil?  In the absence of any, the argument tilts heavily in favor of 
> disallowing it.

I don't disagree with this rationale -- it may be a good idea. But there's a 
question of what's in the API (or runtime documentation in this case) contract. 
What I read here:


developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html

is this:

> Sending Messages to nil
> 
> In Objective-C, it is valid to send a message to nil—it simply has no effect 
> at runtime.


That's pretty unequivocal.

The significance of calling it a bug is that someone might actually file a bug 
report, which might result in Apple either allowing nil in the super case or 
changing the documentation to match the actual behavior. I don't care which is 
the outcome, but I think one of those things should happen.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Quincey Morris]

On May 29, 2011, at 12:20, Jerry Krinock wrote:

> - (id)initWithDocUuid:(NSString*)docUuid {
>NSManagedObjectContext* moc ;
>moc = [[BkmxBasis sharedBasis] exidsMocForIdentifier:docUuid] ;
> 
>self = [super initWithManagedObjectContext:moc
>entityName:constEntityNameStarxid] ;
>if (!self) {
>[super dealloc] ;
>}
> 
>return self ;
> }

To review, there are three points of possible failure in an init method:

- (id) init... {
// do some preparatory things
if (...preparatory things failed...) {
... error point #1 ...
}

self = [super init...];
if (!self)
... error point #2 ...

// do rest of initialization
if (...something goes wrong...) {
... error point #3 ...
}

Error point #2 is easy. Just return nil.

#3 is pretty easy. Clean up things you've already done in this method (such as 
allocating memory), and invoke '[super dealloc]' before returning nil. This is 
still slightly risky, because the super dealloc *could* end up invoking some 
(override) method in this subclass, which -- not having been successfully 
initialized -- could crash. But it's still the best choice, and you should try 
to remember to code your subclass defensively, if you think this situation 
might occur.

#1 is the hard one. You can't return nil, because that would leak the object's 
memory. You can't call super's dealloc, because you don't know if super's 
dealloc is safe to call if super's init hasn't executed. You can't call 
release, because that might call dealloc. You can't free the object's memory 
yourself, because you don't know how (unless you happen to know how it was 
allocated, which in general you don't).

The best choice in a case like this is to avoid doing anything that might fail 
before calling the super init. Or, throw an exception if it fails. Or, call one 
of super's designated initializers anyway, then call super dealloc after it 
returns. Or, I suppose, you could do the least wrong of all the wrong things, 
which would probably be to return nil and leak the object deliberately.

But I don't really know a good answer for case #1.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Ken Thomases]

On May 29, 2011, at 2:43 PM, Quincey Morris wrote:

> The difference in the second case is that the compiler translates it (AFAIK) 
> into a call to objc_msgSendSuper instead of objc_msgSend. What I'm winding up 
> to here is that the failure in messaging a nil 'super' looks to me like a bug 
> in the ObjC runtime's implementation of objc_msgSendSuper.

I wouldn't call it a bug in the Objective-C runtime.  Assuming that self is not 
nil in a call to super is a perfectly reasonable assumption -- consider how 
infrequently it has ever tripped anybody up -- and probably enables some nice 
optimizations.

The whole issue of "messaging nil does nothing but (usually) return zero" is 
somewhat controversial because it can hide bugs.  I don't have a big problem 
with it (and quite like the patterns that it enables).  But it's important to 
recognize that there are good arguments on both sides and the design decision 
involved a tradeoff.  In any case, it doesn't seem to me that that design 
decision necessarily implies that calling super with a nil self should also be 
safe.  The two can be considered separately.  In this case, it was actually 
good that it crashed, since Jerry's code had a bug and it was found earlier 
than it might otherwise have been.  Put another way, what nice patterns would 
be enabled if it were safe to message super when self is nil?  In the absence 
of any, the argument tilts heavily in favor of disallowing it.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Ken Thomases]

On May 29, 2011, at 2:20 PM, Jerry Krinock wrote:

> So, let's look at the subclass init method which invokes -dealloc:
> 
> - (id)initWithDocUuid:(NSString*)docUuid {
>NSManagedObjectContext* moc ;
>moc = [[BkmxBasis sharedBasis] exidsMocForIdentifier:docUuid] ;
> 
>self = [super initWithManagedObjectContext:moc
>entityName:constEntityNameStarxid] ;
>if (!self) {
>[super dealloc] ;
>}
> 
>return self ;
> }
> 
> It seems that either that recommendation is bad, or I misintepreted how to do 
> it.  What's wrong with that init method?

Well, personally, I don't like that recommendation, but far be it from me to 
argue with one of the runtime engineers.  However, you've definitely 
misinterpreted it.

If super's init method fails, then there's nothing for you to do.  First, self 
will be nil, as you've discovered.  Second, super is responsible for having 
cleaned up.

The recommendation was to invoke [super dealloc] if the super's init succeeded, 
but you subsequently can't complete your initialization.  In other words, if 
self is _not_ nil, and you proceed to try to allocate stuff or open a file or 
whatever, but you fail.  In that case, you are responsible for cleaning up and 
returning nil.  The recommendation regards _how_ you clean up.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Quincey Morris]

On May 29, 2011, at 12:20, Jerry Krinock wrote:

> Ah, I get it now.  It's the access to the pointer m_managedObjectContext 
> itself that's the problem.
> 
> So, let's look at the subclass init method which invokes -dealloc:
> 
> - (id)initWithDocUuid:(NSString*)docUuid {
>NSManagedObjectContext* moc ;
>moc = [[BkmxBasis sharedBasis] exidsMocForIdentifier:docUuid] ;
> 
>self = [super initWithManagedObjectContext:moc
>entityName:constEntityNameStarxid] ;
>if (!self) {
>[super dealloc] ;
>}
> 
>return self ;
> }
> 
> It seems that either that recommendation is bad, or I misintepreted how to do 
> it.  What's wrong with that init method?

Actually, I think you misinterpreted how to do it. Remember that 'self' and 
'super' are the same object, and you would never write:

if (!self)
[self someMethod];

OTOH, if you *did* write that, it ought to be harmless because messaging to 
'nil' is harmless. So this *ought* to be harmless too:

if (!self)
[super someMethod];

but you seem to have proved it isn't.

The difference in the second case is that the compiler translates it (AFAIK) 
into a call to objc_msgSendSuper instead of objc_msgSend. What I'm winding up 
to here is that the failure in messaging a nil 'super' looks to me like a bug 
in the ObjC runtime's implementation of objc_msgSendSuper.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?

[Jerry Krinock]

On 2011 May 29, at 11:38, Stephen J. Butler wrote:

> On Sun, May 29, 2011 at 1:30 PM, Jerry Krinock  wrote:
>> I'm really losing it; or maybe I never understood to begin with.  How can 
>> this code crash?
>> 
>>  - (void)dealloc
>>  {
>>  NSLog(@"0988 %p %s", self, __PRETTY_FUNCTION__) ;
>>  NSLog(@"1250 ") ;
>> CRASH->   int myPointer = (int)m_managedObjectContext ;
>>  NSLog(@"1335 myPointer = %d", myPointer) ;
>>  ...
>>  }
>> 
>> stderr output:
>> 
>> 0988 0x0 -[SSYMojo dealloc]
>> 1250
>> Program received signal:  “EXC_BAD_ACCESS”
> 
> This is HIGHLY suspicious. Look at your first line, dealloc is somehow
> getting sent to a nil self … you never call dealloc yourself in code unless
> it's [super dealloc].

Thank you, Stephen.  Indeed, that's how I got there.  A subclass' -init failed 
and sent a [super dealloc] as recommended here:

http://lists.apple.com/archives/Objc-language/2008/Sep/msg00133.html

> Number two, Obj-C short circuits messages to
> "nil" objects: they aren't even called.
> 
> The crash happens because m_managedObjectContext is an instance
> variable (I assume), and there's an implied dereference of self (that
> is, it's really "self->m_managedObjectContext"). Since self is nil,
> you're dereferencing NULL and you get a segfault.


> So the crash is the logical conclusion of dealloc being called on a

> nil object.

Ah, I get it now.  It's the access to the pointer m_managedObjectContext itself 
that's the problem.

So, let's look at the subclass init method which invokes -dealloc:

- (id)initWithDocUuid:(NSString*)docUuid {
NSManagedObjectContext* moc ;
moc = [[BkmxBasis sharedBasis] exidsMocForIdentifier:docUuid] ;

self = [super initWithManagedObjectContext:moc
entityName:constEntityNameStarxid] ;
if (!self) {
[super dealloc] ;
}

return self ;
}

It seems that either that recommendation is bad, or I misintepreted how to do 
it.  What's wrong with that init method?

Jerry

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How can logging a pointer value cause EXC_BAD_ACCESS?

[Stephen J. Butler]

On Sun, May 29, 2011 at 1:30 PM, Jerry Krinock  wrote:
> I'm really losing it; or maybe I never understood to begin with.  How can 
> this code crash?
>
>      - (void)dealloc
>      {
>          NSLog(@"0988 %p %s", self, __PRETTY_FUNCTION__) ;
>          NSLog(@"1250 ") ;
> CRASH->   int myPointer = (int)m_managedObjectContext ;
>          NSLog(@"1335 myPointer = %d", myPointer) ;
>          ...
>      }
>
> stderr output:
>
> 0988 0x0 -[SSYMojo dealloc]
> 1250
> Program received signal:  “EXC_BAD_ACCESS”

This is HIGHLY suspicious. Look at your first line, dealloc is somehow
getting sent to a nil self. I have no idea how you'd end up in such a
situation. For one, you never call dealloc yourself in code unless
it's [super dealloc]. Number two, Obj-C short circuits messages to
"nil" objects: they aren't even called.

The crash happens because m_managedObjectContext is an instance
variable (I assume), and there's an implied dereference of self (that
is, it's really "self->m_managedObjectContext"). Since self is nil,
you're dereferencing NULL and you get a segfault.

So the crash is the logical conclusion of dealloc being called on a
nil object. But I have zero ideas how you even got to that situation
in the first place.

> The line marked CRASH-> is highlighted in blue by Xcode/gdb.  How can this 
> crash?  I wanted to log the pointer value (and it *is* an 'int' since this is 
> 32-bit).  To emphasize this, I assigned it to an int, and it still crashes.  
> I thought that EXC_BAD_ACCESS can only occur if you *access* memory.
>
> Of course, m_managedObjectContext is declared as a pointer to an object in 
> the @interface,
>
> NSManagedObjectContext* m_managedObjectContext ;
>
> I've never seen this happen before.  I know the format specifier %@ can evoke 
> a crash because it sends a -description message.  But not %p or %x or %d.
>
> Just to prove that gravity still pulls downward, I tried this:
>
> NSManagedObjectContext* x = (void*)3 ;
> // Certainly 0x3 is not in my memory space!
> NSLog(@"Hello") ;
> NSLog(@"x=%d", (int)x) ;
> int y = (int)x ;
> NSLog(@"World") ;
> NSLog(@"y=%d", y) ;
>
> stderr output:
>
> Hello
> x=3
> World
> y=3
>
> No crash, as expected!
>
> What might be the difference between this and my -dealloc method?
>
> Jerry
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/stephen.butler%40gmail.com
>
> This email sent to stephen.but...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

How can logging a pointer value cause EXC_BAD_ACCESS?

[Jerry Krinock]

I'm really losing it; or maybe I never understood to begin with.  How can this 
code crash?

  - (void)dealloc
  {
  NSLog(@"0988 %p %s", self, __PRETTY_FUNCTION__) ;
  NSLog(@"1250 ") ;
CRASH->   int myPointer = (int)m_managedObjectContext ;
  NSLog(@"1335 myPointer = %d", myPointer) ;
  ...
  }

stderr output:

0988 0x0 -[SSYMojo dealloc]
1250 
Program received signal:  “EXC_BAD_ACCESS”

The line marked CRASH-> is highlighted in blue by Xcode/gdb.  How can this 
crash?  I wanted to log the pointer value (and it *is* an 'int' since this is 
32-bit).  To emphasize this, I assigned it to an int, and it still crashes.  I 
thought that EXC_BAD_ACCESS can only occur if you *access* memory.

Of course, m_managedObjectContext is declared as a pointer to an object in the 
@interface,

NSManagedObjectContext* m_managedObjectContext ;

I've never seen this happen before.  I know the format specifier %@ can evoke a 
crash because it sends a -description message.  But not %p or %x or %d.

Just to prove that gravity still pulls downward, I tried this:

NSManagedObjectContext* x = (void*)3 ;
// Certainly 0x3 is not in my memory space!
NSLog(@"Hello") ;
NSLog(@"x=%d", (int)x) ;
int y = (int)x ;
NSLog(@"World") ;
NSLog(@"y=%d", y) ;

stderr output:

Hello
x=3
World
y=3

No crash, as expected!

What might be the difference between this and my -dealloc method?

Jerry

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

[Sean McBride]

On Wed, 16 Feb 2011 11:17:27 -0800, Keith Blount said:

>The debugging continues...

You could try valgrind too:


It works decently on Mac OS now (though no Obj-C GC support still)...

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

[Keith Blount]

Hi Bruce,

Many thanks for the reply. Unfortunately that's a little trickier than it 
sounds - my app has around 200,000 lines of code. :) That said, I know that the 
trigger is page layout mode but I've already been through the page layout code 
(and the page-layout-switching code) several times checking for an 
over-release, and there's nothing obvious in there. Given that NSZombieEnabled 
isn't coming up with anything, I'm thinking it could be an un-initiated 
variable somewhere, but again I've been through the classes that seem to be 
part of the trigger and have found nothing untoward.

It's particularly tricky as this crasher does not affect many users and I've 
only now been able to reproduce it, thanks to a user sending me a problem file, 
after three months of knowing it was lurking from reports generated from my 
app's built-in crash reporter. It seems to be down to a particular way a table 
is arranged in an NSTextView in my page layout code, but even then it doesn't 
always happen, and of course the page layout trigger may be a red herring. 
Today I separated the page layout code out into a separate Xcode project, 
placed all of the code and the problem document that seemed to be triggering 
the crash into the separate app... And of course it refused to crash.

The debugging continues...

Thanks again!
All the best,
Keith

--- On Wed, 2/16/11, Bruce Cresanta  wrote:

> From: Bruce Cresanta 
> Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
> To: "Keith Blount" 
> Cc: cocoa-dev@lists.apple.com, "Sean McBride" 
> Date: Wednesday, February 16, 2011, 6:52 PM
> A big clue is in your backtrace:
> 
> #261968    0x98d06f38 in CFRelease
> #261969    0x98d06f38 in CFRelease
> #261970    0x98d06f38 in CFRelease
> #261971    0x98d33c6d in
> _CFAutoreleasePoolPop
> #261972    0x9867d0aa in
> NSPopAutoreleasePool
> #261973    0x9867cfd2 in -[NSAutoreleasePool
> drain]
> #261974    0x986c4596 in
> _NSAppleEventManagerGenericHandler
> #261975    0x91450f58 in
> aeDispatchAppleEvent
> #261976    0x91450e57 in
> dispatchEventAndSendReply
> #261977    0x91450d61 in
> aeProcessAppleEvent
> #261978    0x9519d389 in
> AEProcessAppleEvent
> #261979    0x93b9a9ca in _DPSNextEvent
> #261980    0x93b99fce in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> #261981    0x93b5c247 in -[NSApplication
> run]
> #261982    0x93b542d9 in NSApplicationMain
> #261983    0x0003513a in main at main.m:23
> 
> 
> 
> //
> #261971    0x98d33c6d in
> _CFAutoreleasePoolPop results in  EXC_BAD_ACCESS when
> you release a variable marked as
> autorelease.   Go back through your code and
> make sure you manually haven't released an autoreleased
> variable.
> 
> Bruce
> 
> 
> 
> 
> 
> On Feb 16, 2011, at 11:27 AM, Keith Blount wrote:
> 
> > And the backtrace doesn't help either:
> > 
> > #261968    0x98d06f38 in CFRelease
> > #261969    0x98d06f38 in CFRelease
> > #261970    0x98d06f38 in CFRelease
> > #261971    0x98d33c6d in
> _CFAutoreleasePoolPop
> > #261972    0x9867d0aa in
> NSPopAutoreleasePool
> > #261973    0x9867cfd2 in
> -[NSAutoreleasePool drain]
> > #261974    0x986c4596 in
> _NSAppleEventManagerGenericHandler
> > #261975    0x91450f58 in
> aeDispatchAppleEvent
> > #261976    0x91450e57 in
> dispatchEventAndSendReply
> > #261977    0x91450d61 in
> aeProcessAppleEvent
> > #261978    0x9519d389 in
> AEProcessAppleEvent
> > #261979    0x93b9a9ca in _DPSNextEvent
> > #261980    0x93b99fce in
> -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> > #261981    0x93b5c247 in
> -[NSApplication run]
> > #261982    0x93b542d9 in
> NSApplicationMain
> > #261983    0x0003513a in main at
> main.m:23
> 
> 



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

[Bruce Cresanta]

A big clue is in your backtrace:

#261968 0x98d06f38 in CFRelease
#261969 0x98d06f38 in CFRelease
#261970 0x98d06f38 in CFRelease
#261971 0x98d33c6d in _CFAutoreleasePoolPop
#261972 0x9867d0aa in NSPopAutoreleasePool
#261973 0x9867cfd2 in -[NSAutoreleasePool drain]
#261974 0x986c4596 in _NSAppleEventManagerGenericHandler
#261975 0x91450f58 in aeDispatchAppleEvent
#261976 0x91450e57 in dispatchEventAndSendReply
#261977 0x91450d61 in aeProcessAppleEvent
#261978 0x9519d389 in AEProcessAppleEvent
#261979 0x93b9a9ca in _DPSNextEvent
#261980 0x93b99fce in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#261981 0x93b5c247 in -[NSApplication run]
#261982 0x93b542d9 in NSApplicationMain
#261983 0x0003513a in main at main.m:23



//
#261971 0x98d33c6d in _CFAutoreleasePoolPop results in  EXC_BAD_ACCESS when you 
release a variable marked as autorelease.   Go back through your code and make 
sure you manually haven't released an autoreleased variable.

Bruce





On Feb 16, 2011, at 11:27 AM, Keith Blount wrote:

> And the backtrace doesn't help either:
> 
> #261968   0x98d06f38 in CFRelease
> #261969   0x98d06f38 in CFRelease
> #261970   0x98d06f38 in CFRelease
> #261971   0x98d33c6d in _CFAutoreleasePoolPop
> #261972   0x9867d0aa in NSPopAutoreleasePool
> #261973   0x9867cfd2 in -[NSAutoreleasePool drain]
> #261974   0x986c4596 in _NSAppleEventManagerGenericHandler
> #261975   0x91450f58 in aeDispatchAppleEvent
> #261976   0x91450e57 in dispatchEventAndSendReply
> #261977   0x91450d61 in aeProcessAppleEvent
> #261978   0x9519d389 in AEProcessAppleEvent
> #261979   0x93b9a9ca in _DPSNextEvent
> #261980   0x93b99fce in -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> #261981   0x93b5c247 in -[NSApplication run]
> #261982   0x93b542d9 in NSApplicationMain
> #261983   0x0003513a in main at main.m:23

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

[Keith Blount]

Many thanks for the reply, Sean, much appreciated. Unfortunately still no joy, 
though. I had already tried setting the CFZombieLevel to 3 (and other values - 
sorry, I should have mentioned that), but according to the tech notes, since 
10.5 Core Foundation types are covered by NSZombie anyway (which is probably 
why I couldn't find anything on CFZombieLevel newer than five years old), so I 
don't think adding CFZombieLevel is adding anything over NSZombieEnabled.

The "Hamster Emporium" (!) article looked hopeful, but unfortunately everything 
I've looked at seems to assume you can get some useful information from the 
console - either a selector name using NSZombies or a bad memory address - and 
then proceeds from there, and I'm getting neither. The console reports nothing 
more useful than this, no matter what I try:

tar(7728) malloc: stack logs being written into 
/tmp/stack-logs.7728.tar.XYgOka.index
tar(7728) malloc: stack logs deleted from /tmp/stack-logs.7728.tar.XYgOka.index
Program received signal:  “EXC_BAD_ACCESS”.

(I have MallocStackLogging turned on as well as NSZombieEnabled.)

And the backtrace doesn't help either:

#261968 0x98d06f38 in CFRelease
#261969 0x98d06f38 in CFRelease
#261970 0x98d06f38 in CFRelease
#261971 0x98d33c6d in _CFAutoreleasePoolPop
#261972 0x9867d0aa in NSPopAutoreleasePool
#261973 0x9867cfd2 in -[NSAutoreleasePool drain]
#261974 0x986c4596 in _NSAppleEventManagerGenericHandler
#261975 0x91450f58 in aeDispatchAppleEvent
#261976 0x91450e57 in dispatchEventAndSendReply
#261977 0x91450d61 in aeProcessAppleEvent
#261978 0x9519d389 in AEProcessAppleEvent
#261979 0x93b9a9ca in _DPSNextEvent
#261980 0x93b99fce in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#261981 0x93b5c247 in -[NSApplication run]
#261982 0x93b542d9 in NSApplicationMain
#261983 0x0003513a in main at main.m:23

(Those CFReleases at the top go on and on and on when they appear - other times 
they don't appear at all.)

And everything I turn up on EXC_BAD_ACCESS from searches just provides 
NSZombieEnabled as the answer (unsurprisingly given that it's always worked for 
me in the past, as I say).

I am still slowly working my way through every technique listed in the tech 
note you linked to, though, having gone through it and tried the obvious ones 
first.

Thanks again,
Keith

--- On Tue, 2/15/11, Sean McBride  wrote:

> From: Sean McBride 
> Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
> To: "Keith Blount" , cocoa-dev@lists.apple.com
> Date: Tuesday, February 15, 2011, 8:55 PM
> On Tue, 15 Feb 2011 12:41:51 -0800,
> Keith Blount said:
> 
> >I'm trying to debug an EXC_BAD_ACCESS crash in my
> application and am
> >tearing my hair out trying to find the cause. I have
> NSZombieEnabled set
> >to YES, but this isn't providing me with any
> information (using
> >NSZombieEnabled is always one of the first things I try
> with crashes
> >like this one, and usually it leads to the culprit
> after a bit of work).
> >I've read that zombies don't always help find
> EXC_BAD_ACCESS (for
> >instance if a variable hasn't been initialised or if
> it's a CF type,
> >although I'm not sure if the latter is still true), so
> presumably this
> >is why it's returning nothing for me.
> >
> >So, all I have to go on is an EXC_BAD_ACCESS, and a
> backtrace that seems
> >to be different every time and usually contains none of
> my own methods.
> >For instance:
> 
> Have you read:
> 
> <http://developer.apple.com/library/mac/#technotes/tn2004/tn2124.html>
> specifically the CFZombie stuff?
> 
> and
> 
> <http://sealiesoftware.com/blog/archive/2008/09/22/
> objc_explain_So_you_crashed_in_objc_msgSend.html>
> 
> Might help...
> 
> --
> 
> Sean McBride, B. Eng         
>        s...@rogue-research.com
> Rogue Research           
>            
> www.rogue-research.com
> Mac Software Developer         
>     Montréal, Québec, Canada
> 
> 
> 



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Tracking a EXC_BAD_ACCESS when zombies don't work

[Sean McBride]

On Tue, 15 Feb 2011 12:41:51 -0800, Keith Blount said:

>I'm trying to debug an EXC_BAD_ACCESS crash in my application and am
>tearing my hair out trying to find the cause. I have NSZombieEnabled set
>to YES, but this isn't providing me with any information (using
>NSZombieEnabled is always one of the first things I try with crashes
>like this one, and usually it leads to the culprit after a bit of work).
>I've read that zombies don't always help find EXC_BAD_ACCESS (for
>instance if a variable hasn't been initialised or if it's a CF type,
>although I'm not sure if the latter is still true), so presumably this
>is why it's returning nothing for me.
>
>So, all I have to go on is an EXC_BAD_ACCESS, and a backtrace that seems
>to be different every time and usually contains none of my own methods.
>For instance:

Have you read:

<http://developer.apple.com/library/mac/#technotes/tn2004/tn2124.html>
specifically the CFZombie stuff?

and

<http://sealiesoftware.com/blog/archive/2008/09/22/
objc_explain_So_you_crashed_in_objc_msgSend.html>

Might help...

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Tracking a EXC_BAD_ACCESS when zombies don't work

[Keith Blount]

Hello,

I'm trying to debug an EXC_BAD_ACCESS crash in my application and am tearing my 
hair out trying to find the cause. I have NSZombieEnabled set to YES, but this 
isn't providing me with any information (using NSZombieEnabled is always one of 
the first things I try with crashes like this one, and usually it leads to the 
culprit after a bit of work). I've read that zombies don't always help find 
EXC_BAD_ACCESS (for instance if a variable hasn't been initialised or if it's a 
CF type, although I'm not sure if the latter is still true), so presumably this 
is why it's returning nothing for me.

So, all I have to go on is an EXC_BAD_ACCESS, and a backtrace that seems to be 
different every time and usually contains none of my own methods. For instance:


#0  0x9685eed7 in objc_msgSend
#1  0x2601ee00 in ??
#2  0x98d33c6d in _CFAutoreleasePoolPop
#3  0x9867d0aa in NSPopAutoreleasePool
#4  0x9867cfd2 in -[NSAutoreleasePool drain]
#5  0x986c4596 in _NSAppleEventManagerGenericHandler
#6  0x91450f58 in aeDispatchAppleEvent
#7  0x91450e57 in dispatchEventAndSendReply
#8  0x91450d61 in aeProcessAppleEvent
#9  0x9519d389 in AEProcessAppleEvent
#10 0x93b9a9ca in _DPSNextEvent
#11 0x93b99fce in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#12 0x93b5c247 in -[NSApplication run]
#13 0x93b542d9 in NSApplicationMain
#14 0x3271 in _start
#15 0x31a0 in start

I do at least have a rough idea of the trigger - the trigger is in my page 
layout code. But I've been through the code and everything is initialised and 
I'm not over-releasing anything in that class. I've looked at the places it's 
called from too. (I have a sneaking suspicion it may have something to do with 
init'ing a text view using -initWithFrame:textContainer: which causes the text 
storage to own the text system, but the text storage gets swapped in and out... 
However my app has thousands of people using it, and only a handful have 
experienced these crashes - the trigger seems to be related to tables getting 
laid out too - and it's only today that someone has been able to provide me 
with a file that usually causes this crash when opened.)

If anyone has any suggestions about what I could try next to find the cause, 
I'd be very grateful. I've tried running with ObjectAlloc and Zombies in 
Instruments, but have so far come up blank.

Many thanks and all the best,
Keith


 

Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: EXC_BAD_ACCESS when loading nib

[Kyle Sluder]

On Fri, Jan 28, 2011 at 12:19 PM, Michael LaMorte
 wrote:
> Program received signal:  “EXC_BAD_ACCESS”.

You have a memory management bug somewhere. I'm guessing that you've
failed to retain an NSManagedObject.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

EXC_BAD_ACCESS when loading nib

[Michael LaMorte]

In preparing my application for the Mac App Store, I've hit a roadblock that I 
can't seem to get past.

Originally, my app was written for 10.5 and up, for both Intel and PPC 
machines. Obviously, for submission it needs to be built for 10.6 and Intel 
only. So I made the required changes to the build settings, changing the Base 
SDK to 10.6 and the deployment target to 10.6, and removing all build 
references to PPC. The compiler stayed at GCC 4.2.

I compiled and noticed some depreciated NSFileManager methods, so I went and 
fixed those. Now when I build and run, before the app finishes launching, I get:

Program received signal:  “EXC_BAD_ACCESS”.

Looking at the stack, I see:

#0  0x902a1a76 in _PFFastEntityRangesByType
#1  0x902e3028 in _PF_ManagedObject_WillChangeValueForKeyIndex
#2  0x902e59d6 in -[NSManagedObject willChangeValueForKey:]
#3  0x927ca985 in -[NSNibOutletConnector establishConnection]
#4  0x927c90df in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:]
#5  0x927c71f4 in loadNib
#6  0x927c65ed in +[NSBundle(NSNibLoading) 
_loadNibFile:nameTable:withZone:ownerBundle:]
#7  0x927c64fe in +[NSBundle(NSNibLoading) 
loadNibFile:externalNameTable:withZone:]
#8  0x927c6449 in +[NSBundle(NSNibLoading) loadNibNamed:owner:]
#9  0x927c324d in NSApplicationMain
#10 0x28dc in main at main.m:13

The fact that #10 was black tells me that it's blowing up in main when the nib 
loads... To track down the problem I tried the following:
- Turn on NSZombies
- Add objc_exception_throw and [NSException raise] to the project breakpoints
- In IB, delete all object connections
- In IB, delete all object bindings
- Delete all objects from the nib (objects, NSArrayControllers, windows, 
menus... everything, one at a time)
- Try different compilers
- Roll back to a previous commit and start over

At this point I'm stumped. Any and all advice would be appreciated.
- Mike

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

[Marco Frisan]

Il giorno 17/gen/2011, alle ore 04.04, Kyle Sluder ha scritto:

> On Sun, Jan 16, 2011 at 4:48 PM, Marco Frisan  wrote:
>> Yes I know that. The problem is that I am was not able to find which 
>> pointer. And the reason I am not able to find it is that the line that cause 
>> the application block is:
>> 
>> NSDictionary * attributes = _record.attributes;
>> 
>> inside the numberOfRowsInTableView: method of my custom class 
>> VLVolumeDetailsViewController.
>> 
>> I checked with debugger and _record, that points to a VLDiskItemRecord 
>> object, is not nil.
>> attributes should be not nil too and are retained by the object pointed by 
>> _record when they are initialized.
> 
> Just because they're not nil doesn't mean they point to valid objects.
> The objects might have been freed.
> 
> First, make sure you're using Build & Analyze. This will catch many
> common memory management errors. If that doesn't find the problem, run
> with the Zombies instrument, which will track object allocations and
> frees and pinpoint where your object is going away.
> 
> It is better to do this rather than assume you have "fixed" the
> problem by using -initWithDictionary:copyItems:.
> 
> --Kyle Sluder

Build and Analize builds succefully (no error, no warning, no analize errors). 
I launched Instruments with NSZombieEnabled, and I in this case I got a first 
track...

Finally I discovered this zombie. It was not the NSDictionary of attributes, 
neither my custom object VLDiskItemRecord. And the line pointed by the debugger 
as the cause of the error was not responsible of anything (apparently).
The zombie was a CFArray.

The place where zombie were addressed was was few lines later, where I get the 
two arrays sending allKeys and allValues messages to the _attributes dictionary 
and later, when I send the message objectAtIndex: to one of them, in the method 
tableView:objectValueForTableColumn:row:.

Actually the object pointed by _attributesKeys and _attributesValues were not 
retained.

Though I am surprised that an error in a method cause the debugger to place the 
error in a totally different method.

Thanks you all for help


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

[Ken Thomases]

On Jan 16, 2011, at 10:37 PM, Marco Frisan wrote:

> I verified with Instruments - Leaks the version available on the provided 
> link (since I modified my local copy) and the result is that I have no memory 
> leak.

A leak is when something is under-released.  The most likely culprit in your 
case is something that is over-relaesed.  In other words, you have used the 
wrong tool to investigate.  You should have used the Zombies instrument as was 
previously suggested.

> And, surprise! _attributes points to a NSEvent instance!!!

Again, this is precisely a symptom of over-releasing (or, equivalently, failure 
to retain) an object.  That object has been deallocated and some other object 
now occupies that memory location.


> Using the debugger I discovered that attributesOfItemAtPath:error: does not 
> return a simple NSDictionary, but an instance of NSFileAttributes, a private 
> class that is probably a subclass of NSDictionary. I am inclined to think 
> that the cause of this unpredictable behavior could be the way 
> NSFileAttributes is implemented.

To this I say: 
http://boredzo.org/blog/archives/2010-11-13/four-rules-of-debugging

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

[Marco Frisan]

Il giorno 17/gen/2011, alle ore 03.02, William Squires ha scritto:

> I'd have a look at your object allocations/deallocations with Instruments - 
> this sort of cr*p usually means you over-released something, or you forgot to 
> retain it. Remember that containers have no way of knowing if you 
> over-release an object stored in them from somewhere else. i.e.
> 
> NSString *myBoobooString = [NSString stringWithFormat:@"%@ - %@", @"foo", 
> @"bar"];
> NSString *myGoodString = @"bas"
> NSArray *myOopsieArray = [NSArray arrayWithObjects:myBoobooString, 
> myGoodString, nil];
> [myBoobooString release];
> [myGoodString release];
> ... <- something else happens here
> [myBoobooString release]; <- Instant kablooey when you release the NSArray, 
> or try to enumerate and traverse it!

I verified with Instruments - Leaks the version available on the provided link 
(since I modified my local copy) and the result is that I have no memory leak.

The surprise is that the first execution, using Instruments and Breakpoint 
button activated (even if there is no breakpoint placed in code), did not block.

The second did not block too. But it displayed 28 leaks, that could be the 
number of attributes * 2 (keys and values).

I controlled and controlled again the code 10...50 times and I have not been 
able to find if I actually release something I should not.

Though, the point is that the program, if launched without Instruments, crashes 
exactly when I click over a volume to display the detailed attributes in the 
right table. If I activate Breakpoints button (and so, debugger) Xcode blocks 
at line 20 of  VLDiskItemRecord.m, where there is this code:

@synthesize attributes = _attributes;

If I select the previous call (from the right pop up menu, over the editor 
view, while debugger is still active) Xcode points to line 57 of 
VLVolumeDetailsViewController.m, inside the implementation of method 
numberOfRowsInTableView:. So, the code that actually causes the error (as I 
already explained) is:

NSDictionary * attributes = _record.attributes;

We can exclude that the cause could be "NSDictionary * attributes = " ;-)

So the problem is "_record" or ".attributes". Based on the Xcode behavior, I am 
inclined to think it is ".attributes".

Then, what I did is to place a breakpoint the line before where I test for 
_record nullity. Launched the program. Press continue once, since the first 
time the method is called there is no volume selected. And then, I selected a 
volume. Application stopped at that line and I passed the mouse over _record to 
see its state (yellow pop-up views, with expansions arrows, the same info you 
can get from debugger window).
And, surprise! _attributes points to a NSEvent instance!!!

Though _attributes was obtained calling attributesOfItemAtPath:error:, no error 
was produced, and I retained it... to be honest I did not, though I corrected 
it and retained _attributes but result does not change. I get the 
EXC_BAD_ACCESS error even if i do [[_attributes retain] retain].
And now, after retaining _attributes, if I verify the state of _record at the 
nullity test line, _attributes points correctly to a NSDictionary.

So, my conclusions are: ?

There is no possible control over dictionaries returned by convenience methods? 
I have to make copies of them every time I need one?

For now I resolved with initWithDictionary:copyItems:.

Thanks

P.S. I just made some changes to initAttributes method in VLDiskItemRecord.m:

- (void)initAttributes {
NSLog(@"%s", __FUNCTION__);

NSError * error = nil;
NSFileManager * fm = [NSFileManager defaultManager];
NSDictionary * attr = [fm attributesOfItemAtPath:_mountPoint 
error:&error];

if (error != nil || attr == nil) {
NSLog(@"Impossible to get attributes for path \"%@\". Reason: 
%@",
  _mountPoint,
  [error localizedDescription]);

_attributes = nil;

return;
}

_attributes = [attr retain];
}

Using the debugger I discovered that attributesOfItemAtPath:error: does not 
return a simple NSDictionary, but an instance of NSFileAttributes, a private 
class that is probably a subclass of NSDictionary. I am inclined to think that 
the cause of this unpredictable behavior could be the way NSFileAttributes is 
implemented.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

[Kyle Sluder]

On Sun, Jan 16, 2011 at 4:48 PM, Marco Frisan  wrote:
> Yes I know that. The problem is that I am was not able to find which pointer. 
> And the reason I am not able to find it is that the line that cause the 
> application block is:
>
> NSDictionary * attributes = _record.attributes;
>
> inside the numberOfRowsInTableView: method of my custom class 
> VLVolumeDetailsViewController.
>
> I checked with debugger and _record, that points to a VLDiskItemRecord 
> object, is not nil.
> attributes should be not nil too and are retained by the object pointed by 
> _record when they are initialized.

Just because they're not nil doesn't mean they point to valid objects.
The objects might have been freed.

First, make sure you're using Build & Analyze. This will catch many
common memory management errors. If that doesn't find the problem, run
with the Zombies instrument, which will track object allocations and
frees and pinpoint where your object is going away.

It is better to do this rather than assume you have "fixed" the
problem by using -initWithDictionary:copyItems:.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

[Marco Frisan]

Il giorno 16/gen/2011, alle ore 19.06, Kyle Sluder ha scritto:

> On Jan 15, 2011, at 3:55 AM, Marco Frisan  wrote:
> 
>> I don't understand why _record.attributes causes a “EXC_BAD_ACCESS” signal.
> 
> This is the defining characteristic of a memory management bug: you have a 
> pointer to an object that has since been freed. Trying to use that pointer is 
> an error.
> 
> --Kyle Sluder


Yes I know that. The problem is that I am was not able to find which pointer. 
And the reason I am not able to find it is that the line that cause the 
application block is:

NSDictionary * attributes = _record.attributes;

inside the numberOfRowsInTableView: method of my custom class 
VLVolumeDetailsViewController.

I checked with debugger and _record, that points to a VLDiskItemRecord object, 
is not nil.
attributes should be not nil too and are retained by the object pointed by 
_record when they are initialized.

Though it seems that I resolved it using initWithDictionary:copyItems: and 
passing YES as its second parameter, to create a copy of the attributes 
dictionary, instead of simply retain the one returned by 
attributesOfItemAtPath:error:. Though I do not understand yet which was the 
object freed in the previous approach.

--Marco Frisan
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: “EXC_BAD_ACCESS” object is not nil but not accessible

[Kyle Sluder]

On Jan 15, 2011, at 3:55 AM, Marco Frisan  wrote:

> I don't understand why _record.attributes causes a “EXC_BAD_ACCESS” signal.

This is the defining characteristic of a memory management bug: you have a 
pointer to an object that has since been freed. Trying to use that pointer is 
an error.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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