Re: Odd Crash

[Peter Hudson]

‎I had a feeling something has changed about the order the OS does things in. 
I'll go hunting !

Many thanks. 

Peter
  Original Message  
From: Scott Ribe
Sent: Thursday, 24 September 2015 17:15
To: Peter Hudson
Cc: Jens Alfke; cocoa-dev@lists.apple.com
Subject: Re: Odd Crash

On Sep 24, 2015, at 10:06 AM, Peter Hudson  wrote:
> 
> This problem occurs after I have run a sheet - might that be part of the 
> issue? 

Definitely turn zombies on. I'd suspect that some of your code might be 
confused about what window is closing when the sheet is dismissed, and is 
dealloc'ing something early.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: Odd Crash

[Scott Ribe]

On Sep 24, 2015, at 10:06 AM, Peter Hudson  wrote:
> 
> This problem occurs after I have run a sheet - might that be part of the 
> issue? 

Definitely turn zombies on. I'd suspect that some of your code might be 
confused about what window is closing when the sheet is dismissed, and is 
dealloc'ing something early.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: Odd Crash

[Scott Ribe]

On Sep 24, 2015, at 10:02 AM, Jens Alfke  wrote:
> 
> This is a pretty common type of crash. You’ve got an NSTableView whose 
> dataSource has been dealloced, so it tried to call the dataSource and crashed.
> If you want to catch this in the debugger, turn Zombie Objects on.
> Most likely the problem is that the window got closed but not released, so it 
> and its views are still in memory.

There's another possibility:

Switching from older SDK to 10.9 or 10.10 (I forget which) changed some order 
of operations.

Used to be: once window controller -close was called, everything went dead, and 
you could tear down table views, controllers, delegates, data sources in pretty 
much any order you wanted.

The new way: the frigging thing will try to redraw itself after -close, 
actually after invoking willClose on its window controller, and you have to 
tear things down in a very specific order.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(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: Odd Crash

[Peter Hudson]

Thanks for replying Jens. 
Your suggestion is why I thought the crash was odd - the window has not been 
closed and is still there. 
This problem occurs after I have run a sheet - might that be part of the issue? 

Peter

  Original Message  
From: Jens Alfke
Sent: Thursday, 24 September 2015 17:03
To: Peter Hudson
Cc: cocoa-dev@lists.apple.com
Subject: Re: Odd Crash

This is a pretty common type of crash. You’ve got an NSTableView whose 
dataSource has been dealloced, so it tried to call the dataSource and crashed.
If you want to catch this in the debugger, turn Zombie Objects on.
Most likely the problem is that the window got closed but not released, so it 
and its views are still in memory.

—Jens

> On Sep 24, 2015, at 8:23 AM, Peter Hudson  wrote:
> 
> Suddenly, after a long period of clean operation, I start to this crash.
> 
> I’ve copied the last section of the crash report from the user. 
> 
> Any suggestions appreciated.
> 
> 
> Peter
> 
> 
> Date/Time: 2015-09-24 15:38:49.222 +0100
> OS Version: Mac OS X 10.10.4 (14E46)
> Report Version: 11
> Anonymous UUID: 899431F1-88F0-529E-0D17-073884EE9FDA
> 
> Sleep/Wake UUID: B8985A4A-CC24-42C6-89F0-32993D38777B
> 
> Time Awake Since Boot: 21000 seconds
> Time Since Wake: 14000 seconds
> 
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
> 
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x06e7a000
> 
> VM Regions Near 0x6e7a000:
> CG shared images 06e6a000-06e7a000 [ 64K] r--/r-- SM=SHM 
> --> 
> CoreAnimation 06e7c000-06e82000 [ 24K] rw-/rwx SM=SHM 
> 
> Application Specific Information:
> objc_msgSend() selector name: tableView:objectValueForTableColumn:row:
> Performing @selector(runSheetEditPostHeaderPreFooter:) from sender NSMenuItem 
> 0x7b07ab80
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 libobjc.A.dylib 
> 0x98a840a7 objc_msgSend + 23
> 1 com.apple.AppKit 
> 0x980ec80b -[NSTableView preparedCellAtColumn:row:] + 385
> 2 com.apple.AppKit 
> 0x9811cba1 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878
> 3 com.apple.AppKit 
> 0x9811c2ae -[NSTableView _windowChangedKeyState] + 323
> 4 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 5 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 6 com.apple.AppKit 
> 0x97f9483f -[NSScrollView _windowChangedKeyState] + 50
> 7 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 8 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 9 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 10 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 11 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 12 com.apple.AppKit 
> 0x9808223d -[NSSplitView _windowChangedKeyState] + 71
> 13 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 14 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 15 com.apple.AppKit 
> 0x9805ca16 -[NSTabView _windowChangedKeyState] + 50
> 16 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 17 com.apple.AppKit 
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 18 com.apple.AppKit 
> 0x97f9450a -[NSFrameView _windowChangedKeyState] + 101
> 19 com.apple.AppKit 
> 0x97f94430 -[NSThemeFrame _windowChangedKeyState] + 51
> 20 com.apple.AppKit 
> 0x980d90fe -[NSWindow(NSSheets) _orderFrontRelativeToWindow:] + 236
> 21 com.apple.AppKit 
> 0x97f9bfe2 -[NSWindow 
> _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 2502
> 22 com.apple.AppKit 
> 0x97f9b607 -[NSWindow 
> _doOrderWindowWithoutAnimation:relativeTo:findKey:forCounter:force:isModal:] 
> + 81
> 23 com.apple.AppKit 
> 0x97f9b03b -[NSWindow 
> _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 856
> 24 com.apple.AppKit 
> 0x980ce205 -[NSApplication _orderFrontModalWindow:relativeToWindow:] + 811
> 25 com.apple.AppKit 
> 0x980cdaf1 -[NSApplication 
> _commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:]
>  + 913
> 26 com.apple.AppKit 
> 0x98153b6f -[NSApplication 
> beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:] + 154
> 27 WattWenn 
> 0x0012956d -[SSScriptDoc(EDIT_POSTHEADER_PREFOOTER_STRIPS_WINDOW_SUPPORT) 
> runSheetEditPostHeaderPreFooter:] + 1837
> 28 libobjc.A.dylib 
> 0x98a8b853 -[NSObject performSelector:withObject:] + 70
> 29 com.apple.AppKit 
> 0x980c8c1e __36-[NSApplication sendAction:to:from:]_block_invoke + 51
> 30 libsystem_trace.dylib 
> 
> ___
> 
>

Re: Odd Crash

[Jens Alfke]

This is a pretty common type of crash. You’ve got an NSTableView whose 
dataSource has been dealloced, so it tried to call the dataSource and crashed.
If you want to catch this in the debugger, turn Zombie Objects on.
Most likely the problem is that the window got closed but not released, so it 
and its views are still in memory.

—Jens

> On Sep 24, 2015, at 8:23 AM, Peter Hudson  wrote:
> 
> Suddenly, after a long period of clean operation, I start to this crash.
> 
> I’ve copied the last section of the crash report from the user. 
> 
> Any suggestions appreciated.
> 
> 
> Peter
> 
> 
> Date/Time: 2015-09-24 15:38:49.222 +0100
> OS Version:Mac OS X 10.10.4 (14E46)
> Report Version:11
> Anonymous UUID:899431F1-88F0-529E-0D17-073884EE9FDA
> 
> Sleep/Wake UUID:   B8985A4A-CC24-42C6-89F0-32993D38777B
> 
> Time Awake Since Boot: 21000 seconds
> Time Since Wake:   14000 seconds
> 
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x06e7a000
> 
> VM Regions Near 0x6e7a000:
>CG shared images   06e6a000-06e7a000 [   64K] r--/r-- 
> SM=SHM  
> --> 
>CoreAnimation  06e7c000-06e82000 [   24K] rw-/rwx 
> SM=SHM  
> 
> Application Specific Information:
> objc_msgSend() selector name: tableView:objectValueForTableColumn:row:
> Performing @selector(runSheetEditPostHeaderPreFooter:) from sender NSMenuItem 
> 0x7b07ab80
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libobjc.A.dylib   
> 0x98a840a7 objc_msgSend + 23
> 1   com.apple.AppKit  
> 0x980ec80b -[NSTableView preparedCellAtColumn:row:] + 385
> 2   com.apple.AppKit  
> 0x9811cba1 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878
> 3   com.apple.AppKit  
> 0x9811c2ae -[NSTableView _windowChangedKeyState] + 323
> 4   com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 5   com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 6   com.apple.AppKit  
> 0x97f9483f -[NSScrollView _windowChangedKeyState] + 50
> 7   com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 8   com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 9   com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 10  com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 11  com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 12  com.apple.AppKit  
> 0x9808223d -[NSSplitView _windowChangedKeyState] + 71
> 13  com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 14  com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 15  com.apple.AppKit  
> 0x9805ca16 -[NSTabView _windowChangedKeyState] + 50
> 16  com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 17  com.apple.AppKit  
> 0x97f94671 -[NSView _windowChangedKeyState] + 276
> 18  com.apple.AppKit  
> 0x97f9450a -[NSFrameView _windowChangedKeyState] + 101
> 19  com.apple.AppKit  
> 0x97f94430 -[NSThemeFrame _windowChangedKeyState] + 51
> 20  com.apple.AppKit  
> 0x980d90fe -[NSWindow(NSSheets) _orderFrontRelativeToWindow:] + 236
> 21  com.apple.AppKit  
> 0x97f9bfe2 -[NSWindow 
> _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 2502
> 22  com.apple.AppKit  
> 0x97f9b607 -[NSWindow 
> _doOrderWindowWithoutAnimation:relativeTo:findKey:forCounter:force:isModal:] 
> + 81
> 23  com.apple.AppKit  
> 0x97f9b03b -[NSWindow 
> _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 856
> 24  com.apple.AppKit  
> 0x980ce205 -[NSApplication _orderFrontModalWindow:relativeToWindow:] + 811
> 25  com.apple.AppKit  
> 0x980cdaf1 -[NSApplication 
> _commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:]
>  + 913
> 26  com.apple.AppKit  
> 0x98153b6f -[NSApplication 
> beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:] + 154
> 27  WattWenn  
> 0x0012956d -[SSScriptDoc(EDIT_POSTHEADER_PREFOOTER_STRIPS_WINDOW_SUPPORT) 
> runSheetEditPostHeaderPreFooter:] + 1837
> 28  libobjc.A.dylib   
> 0x98a8b853 -[NSObject performSelector:withObject:] + 70
> 29  com.apple.AppKit  
> 0x980c8c1e __36-[NSApplication sendAction:to:from:]_block_invoke + 51
> 30  libsystem_trace.dylib 
> 
> ___
> 
> 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-

Odd Crash

[Peter Hudson]

Suddenly, after a long period of clean operation, I start to this crash.

I’ve copied the last section of the crash report from the user. 

Any suggestions appreciated.


Peter


Date/Time: 2015-09-24 15:38:49.222 +0100
OS Version:Mac OS X 10.10.4 (14E46)
Report Version:11
Anonymous UUID:899431F1-88F0-529E-0D17-073884EE9FDA

Sleep/Wake UUID:   B8985A4A-CC24-42C6-89F0-32993D38777B

Time Awake Since Boot: 21000 seconds
Time Since Wake:   14000 seconds

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x06e7a000

VM Regions Near 0x6e7a000:
CG shared images   06e6a000-06e7a000 [   64K] r--/r-- 
SM=SHM  
--> 
CoreAnimation  06e7c000-06e82000 [   24K] rw-/rwx 
SM=SHM  

Application Specific Information:
objc_msgSend() selector name: tableView:objectValueForTableColumn:row:
Performing @selector(runSheetEditPostHeaderPreFooter:) from sender NSMenuItem 
0x7b07ab80

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib   
0x98a840a7 objc_msgSend + 23
1   com.apple.AppKit  
0x980ec80b -[NSTableView preparedCellAtColumn:row:] + 385
2   com.apple.AppKit  
0x9811cba1 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878
3   com.apple.AppKit  
0x9811c2ae -[NSTableView _windowChangedKeyState] + 323
4   com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
5   com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
6   com.apple.AppKit  
0x97f9483f -[NSScrollView _windowChangedKeyState] + 50
7   com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
8   com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
9   com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
10  com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
11  com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
12  com.apple.AppKit  
0x9808223d -[NSSplitView _windowChangedKeyState] + 71
13  com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
14  com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
15  com.apple.AppKit  
0x9805ca16 -[NSTabView _windowChangedKeyState] + 50
16  com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
17  com.apple.AppKit  
0x97f94671 -[NSView _windowChangedKeyState] + 276
18  com.apple.AppKit  
0x97f9450a -[NSFrameView _windowChangedKeyState] + 101
19  com.apple.AppKit  
0x97f94430 -[NSThemeFrame _windowChangedKeyState] + 51
20  com.apple.AppKit  
0x980d90fe -[NSWindow(NSSheets) _orderFrontRelativeToWindow:] + 236
21  com.apple.AppKit  
0x97f9bfe2 -[NSWindow 
_reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 2502
22  com.apple.AppKit  
0x97f9b607 -[NSWindow 
_doOrderWindowWithoutAnimation:relativeTo:findKey:forCounter:force:isModal:] + 
81
23  com.apple.AppKit  
0x97f9b03b -[NSWindow 
_doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 856
24  com.apple.AppKit  
0x980ce205 -[NSApplication _orderFrontModalWindow:relativeToWindow:] + 811
25  com.apple.AppKit  
0x980cdaf1 -[NSApplication 
_commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:]
 + 913
26  com.apple.AppKit  
0x98153b6f -[NSApplication 
beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:] + 154
27  WattWenn  
0x0012956d -[SSScriptDoc(EDIT_POSTHEADER_PREFOOTER_STRIPS_WINDOW_SUPPORT) 
runSheetEditPostHeaderPreFooter:] + 1837
28  libobjc.A.dylib   
0x98a8b853 -[NSObject performSelector:withObject:] + 70
29  com.apple.AppKit  
0x980c8c1e __36-[NSApplication sendAction:to:from:]_block_invoke + 51
30  libsystem_trace.dylib 

___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Andy Lee]

On Jan 20, 2011, at 9:39 PM, Corbin Dunn wrote:
> Now for something like a button, it obviously won't run into this type of 
> latent drawing issue, since they don't message the delegate every time they 
> draw. However, if you temporarily allocated an object and set it as the 
> target/action of a button, and then free that object while the button is 
> still visible, then yes, that's a case where you want to reset it to nil.

I don't know why I had it in my mind that targets are retained.  If they were, 
they'd run into the same retain cycles as delegates would if *they* were 
retained.

I think it would be going to extremes to nil out button targets in dealloc.  I 
think a common-sense approach is best after all, and I retracted the bug I 
mentioned earlier because checking delegates for == self should be up to the 
discretion of the programmer.  Can't hurt to do it, but it almost certainly 
won't matter.

--Andy

___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Andy Lee]

On Jan 20, 2011, at 8:51 PM, Eric Gorr wrote:
> On Jan 20, 2011, at 4:27 PM, Corbin Dunn wrote:
[...]
>> Yes, please do file a bug. The sample should set the delegate/datasource to 
>> nil, as it is good practice to do so, and we can update the sample.
> 
> Bug filed:  rdar://8896270

I just submitted rdar://8896532, referencing Eric's bug, suggesting that before 
nilling out the delegate and dataSource, you should check whether they are == 
self.  Conceivably at some point the delegate and/or dataSource might have been 
set to some other object -- probably not in this example, but in general.  
Admittedly it's probably very rare that this is an issue, and I'd be surprised 
if anyone on this list has ever run into a bug because of it.  On the other 
hand, if you're going to program defensively, why not go all the way?  On the 
*other* hand, maybe this is one of those things that should be at the 
programmer's discretion rather than a hard and fast rule.

--Andy (just now realizing I haven't been checking for == self myself)

___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Corbin Dunn]

On Jan 20, 2011, at 1:33 PM, Abdul Sowayan wrote:

> Hi Corbin,
> 
> 
>> I wrote that sample, and gave the WWDC talk based on it a few years ago. I
>> also "own" NSTableView.
>> 
>> Yes, please do file a bug. The sample should set the delegate/datasource to
>> nil, as it is good practice to do so, and we can update the sample.
> 
> Thanks for the clarification, it is very helpful. So the right thing to do
> with delegates/datasources is to set them to nil.
> 
> What about target/action on something like a button?
> 
> Would you say that for every control in a nib, one has to set the
> delegate/datasource/action to nil? While this might seem like a silly
> question, most books/examples I read don't do this so I wanted to be clear
> on what the right thing to do is.

No, I wouldn't say every control -- I would say any control that has a delegate 
method which responds to drawing commands. Things like NSTableView, 
NSOutlineView, NSBrowser, NSWindow. I mainly know from experience of debugging 
and looking at crash reports.

Now for something like a button, it obviously won't run into this type of 
latent drawing issue, since they don't message the delegate every time they 
draw. However, if you temporarily allocated an object and set it as the 
target/action of a button, and then free that object while the button is still 
visible, then yes, that's a case where you want to reset it to nil.

Most these type of crashing issues can easily be resolved by using instruments 
+ zombies -- you quickly realize your object was deallocated, but the view 
object had a reference to it.

corbin


___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Eric Gorr]

On Jan 20, 2011, at 4:27 PM, Corbin Dunn wrote:

> Hi Eric,
> 
> On Jan 20, 2011, at 9:26 AM, Eric Gorr wrote:
> 
>> 
>> On Jan 20, 2011, at 12:17 PM, Kyle Sluder wrote:
>> 
>>> On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr  wrote:
 Based on my current understanding, the dealloc should be setting it's 
 datasource and delegate to nil. Correct? If so, I will file a bug.
>>> 
>>> No. It is the responsibility of the delegate to set the table view's
>>> backpointer to nil. The delegate usually has an owning reference to
>>> the table view. If -dealloc is being called on the table view, but the
>>> delegate still has a pointer to the table view, that means a memory
>>> management error has occurred.
>> 
>> I think you misunderstood and I didn't write that sentence as clearly as I 
>> could.
>> 
>> For a specific example, check out the AnimatedTableView sample code from 
>> Apple.  The ATColorTableController class is a datasource for the table, but 
>> it's dealloc looks like:
>> 
>> - (void)dealloc 
>> {
>>   [_colorList release];
>>   [_colorNames release];
>>   [_window release];
>>   [super dealloc];
>> }
>> 
>> Based on my current understanding, the table controller's dealloc (above) 
>> should be setting the table datasource and delegate to nil. Correct? If so, 
>> I will file a bug.
> 
> I wrote that sample, and gave the WWDC talk based on it a few years ago. I 
> also "own" NSTableView.
> 
> Yes, please do file a bug. The sample should set the delegate/datasource to 
> nil, as it is good practice to do so, and we can update the sample.

Bug filed:  rdar://8896270

> thanks for catching this!

You're welcome.

This has been a very interesting thread.



___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Eric Gorr]

On Jan 20, 2011, at 4:56 PM, Sean McBride wrote:

> On Thu, 20 Jan 2011 13:27:35 -0800, Corbin Dunn said:
> 
>>> For a specific example, check out the AnimatedTableView sample code
>> from Apple.  The ATColorTableController class is a datasource for the
>> table, but it's dealloc looks like:
>>> 
>>> - (void)dealloc
>>> {
>>>  [_colorList release];
>>>  [_colorNames release];
>>>  [_window release];
>>>  [super dealloc];
>>> }
>>> 
>>> Based on my current understanding, the table controller's dealloc
>> (above) should be setting the table datasource and delegate to nil.
>> Correct? If so, I will file a bug.
>> 
>> I wrote that sample, and gave the WWDC talk based on it a few years ago.
>> I also "own" NSTableView.
>> 
>> Yes, please do file a bug. The sample should set the delegate/datasource
>> to nil, as it is good practice to do so, and we can update the sample.
> 
> In the case of garbage collected-only mode, do I assume correctly that
> such setting to nil is not needed?


I thought this might be of interestMike Ash writes:

-
http://www.mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html
If you're using garbage collection in Objective-C, then good news! The 
Objective-C garbage collector already supports zeroing weak references using 
the type modifier __weak. You can just declare any instance variable like so:

__weak id _foo;
And it's automatically a zeroing weak reference. The compiler takes care of 
emitting the appropriate read/write barriers so that access is always safe.
-



___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Sean McBride]

On Thu, 20 Jan 2011 13:27:35 -0800, Corbin Dunn said:

>> For a specific example, check out the AnimatedTableView sample code
>from Apple.  The ATColorTableController class is a datasource for the
>table, but it's dealloc looks like:
>>
>> - (void)dealloc
>> {
>>   [_colorList release];
>>   [_colorNames release];
>>   [_window release];
>>   [super dealloc];
>> }
>>
>> Based on my current understanding, the table controller's dealloc
>(above) should be setting the table datasource and delegate to nil.
>Correct? If so, I will file a bug.
>
>I wrote that sample, and gave the WWDC talk based on it a few years ago.
>I also "own" NSTableView.
>
>Yes, please do file a bug. The sample should set the delegate/datasource
>to nil, as it is good practice to do so, and we can update the sample.

In the case of garbage collected-only mode, do I assume correctly that
such setting to nil is not needed?

--

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: Odd Crash when adding table columns manually

[Lee Ann Rucker]

On Jan 20, 2011, at 1:24 PM, Corbin Dunn wrote:


On Jan 19, 2011, at 4:51 PM, Lee Ann Rucker wrote:


On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:


In general, it is good practice in your apps to set your delegate and 
datasource to nil. Who is to say something might cause a draw to happen, which 
would then message your (now dealloced) delegate? Ideally, NSTableView 
shouldn't message the delegate/datasource after the window is closed, but 
something extra "setNeedsDisplay" messages get thrown into it, causing it to 
happen, and crash. That is why your bug happened. 6728942 made an effort to 
reduce the display message.


If I'd set them in my code I would agree, but I expect that if it's set by the 
nib setup code then it should cleared by the nib cleanup code.

Yes, and it works in the majority of cases. It's the cases where the programmer 
does something extra (that causes a redisplay), and doesn't understand why it 
has side effects (redrawing, and subsequently delegate callbacks). There is no 
nib cleanup code; the nib doesn't have any way of zero-ing out references.

If you do have a case where you think AppKit should be cleaning it up, then 
please submit it to bugreporter.apple.com -- it 
is possible that in some cases we may be able to make it work better.

Now that I dig, it was a Snow Leopard beta bug that got fixed before it 
shipped, so despite the similar fix/workaround this is a different issue. I 
miss the real Radar, where I could actually see the bug my bug was a duplicate 
of :)


___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Abdul Sowayan]

Hi Corbin,


> I wrote that sample, and gave the WWDC talk based on it a few years ago. I
> also "own" NSTableView.
> 
> Yes, please do file a bug. The sample should set the delegate/datasource to
> nil, as it is good practice to do so, and we can update the sample.

Thanks for the clarification, it is very helpful. So the right thing to do
with delegates/datasources is to set them to nil.

What about target/action on something like a button?

Would you say that for every control in a nib, one has to set the
delegate/datasource/action to nil? While this might seem like a silly
question, most books/examples I read don't do this so I wanted to be clear
on what the right thing to do is.

Thanks again,
Abdul

___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Corbin Dunn]

Hi Eric,

On Jan 20, 2011, at 9:26 AM, Eric Gorr wrote:

> 
> On Jan 20, 2011, at 12:17 PM, Kyle Sluder wrote:
> 
>> On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr  wrote:
>>> Based on my current understanding, the dealloc should be setting it's 
>>> datasource and delegate to nil. Correct? If so, I will file a bug.
>> 
>> No. It is the responsibility of the delegate to set the table view's
>> backpointer to nil. The delegate usually has an owning reference to
>> the table view. If -dealloc is being called on the table view, but the
>> delegate still has a pointer to the table view, that means a memory
>> management error has occurred.
> 
> I think you misunderstood and I didn't write that sentence as clearly as I 
> could.
> 
> For a specific example, check out the AnimatedTableView sample code from 
> Apple.  The ATColorTableController class is a datasource for the table, but 
> it's dealloc looks like:
> 
> - (void)dealloc 
> {
>   [_colorList release];
>   [_colorNames release];
>   [_window release];
>   [super dealloc];
> }
> 
> Based on my current understanding, the table controller's dealloc (above) 
> should be setting the table datasource and delegate to nil. Correct? If so, I 
> will file a bug.

I wrote that sample, and gave the WWDC talk based on it a few years ago. I also 
"own" NSTableView.

Yes, please do file a bug. The sample should set the delegate/datasource to 
nil, as it is good practice to do so, and we can update the sample.

In practice, I didn't notice any issues with the table redrawing after the 
delegate was freed.

thanks for catching this!

--corbin





___

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: Odd Crash when adding table columns manually

[Corbin Dunn]

On Jan 19, 2011, at 4:51 PM, Lee Ann Rucker wrote:

> 
> On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:
> 
>> 
>> In general, it is good practice in your apps to set your delegate and 
>> datasource to nil. Who is to say something might cause a draw to happen, 
>> which would then message your (now dealloced) delegate? Ideally, NSTableView 
>> shouldn't message the delegate/datasource after the window is closed, but 
>> something extra "setNeedsDisplay" messages get thrown into it, causing it to 
>> happen, and crash. That is why your bug happened. 6728942 made an effort to 
>> reduce the display message.
>> 
> 
> If I'd set them in my code I would agree, but I expect that if it's set by 
> the nib setup code then it should cleared by the nib cleanup code.

Yes, and it works in the majority of cases. It's the cases where the programmer 
does something extra (that causes a redisplay), and doesn't understand why it 
has side effects (redrawing, and subsequently delegate callbacks). There is no 
nib cleanup code; the nib doesn't have any way of zero-ing out references. 

If you do have a case where you think AppKit should be cleaning it up, then 
please submit it to bugreporter.apple.com -- it is possible that in some cases 
we may be able to make it work better. 

-corbin



___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Abdul Sowayan]

Hi folks,

I'm trying to figure out a clear guideline on how to handle weak references.
Let's consider the following scenarios:

1- Say I have a button, and set its action/target (via a nib file) to call
method on the controller. In the controller dealloc method, should the
controller set the action/target of the button to nill?

2- Say I have a table view, and set its datasource/delegate (via a nib file)
to the controller. In the controller dealloc method, should the controller
set the datasource/delegate of the tableview to nill?


What I'm interested in is what is the right thing to do here. That is, is
the lack of explicit setting to nil of action/datasource/delegate to nill a
bug?



Thanks,
Abdul

___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Quincey Morris]

On Jan 20, 2011, at 07:22, Eric Gorr wrote:

> I was wondering why this was such a surprise to me, so I went hunting through 
> sample code, books, etc.
> 
> I cannot seem to find any sample code, either in books (even Cocoa 
> Programming for Mac OS X (3rd Edition)) or in Apple's own sample code where 
> they follow these rules. I think that is why it has surprised me. I sure 
> there must be some out there that do follow these rules, but the examples 
> seem to be rare at the moment.

Well, any answer to that is likely to be a bit speculative, but I think at 
least the following factors enter into it:

1. Apple people having been making this point for some time, but it hasn't 
widely been taken up by third party developers. This is one of those policies 
that's been more "honored in the breach".

2. In many cases, failing to adhere to the policy *doesn't* lead to a crash, 
for unrelated reasons (the relevant objects are already owned by something 
else, for example).

3. As you've noted, it can be hard to keep a firm grip on which object needs to 
do what to whom at which time, especially when there are multiple delegate 
patterns in play. Sometimes it's tempting *not* to think it through, but just 
to do something or other, and wait to see if it fails. That's possibly what 
happened to the sample 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Eric Gorr]

On Jan 20, 2011, at 12:17 PM, Kyle Sluder wrote:

> On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr  wrote:
>> Based on my current understanding, the dealloc should be setting it's 
>> datasource and delegate to nil. Correct? If so, I will file a bug.
> 
> No. It is the responsibility of the delegate to set the table view's
> backpointer to nil. The delegate usually has an owning reference to
> the table view. If -dealloc is being called on the table view, but the
> delegate still has a pointer to the table view, that means a memory
> management error has occurred.

I think you misunderstood and I didn't write that sentence as clearly as I 
could.

For a specific example, check out the AnimatedTableView sample code from Apple. 
 The ATColorTableController class is a datasource for the table, but it's 
dealloc looks like:

- (void)dealloc 
{
   [_colorList release];
   [_colorNames release];
   [_window release];
   [super dealloc];
}

Based on my current understanding, the table controller's dealloc (above) 
should be setting the table datasource and delegate to nil. Correct? If so, I 
will file a bug.

Or, what is the reason why the code as written is correct?

___

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: Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Kyle Sluder]

On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr  wrote:
> Based on my current understanding, the dealloc should be setting it's 
> datasource and delegate to nil. Correct? If so, I will file a bug.

No. It is the responsibility of the delegate to set the table view's
backpointer to nil. The delegate usually has an owning reference to
the table view. If -dealloc is being called on the table view, but the
delegate still has a pointer to the table view, that means a memory
management error has occurred.

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

Cleaning up weak references ( was Re: Odd Crash when adding table columns manually )

[Eric Gorr]

On Jan 19, 2011, at 8:24 PM, Eric Gorr wrote:

> On Jan 19, 2011, at 8:19 PM, Graham Cox wrote:
> 
>> On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
>> 
>>> The table is also owned by the the scrolling view and therefore the window 
>>> and would not be deallocated here...it will stick around long after the 
>>> controller is deallocated.
>> 
>> You're right, but since the table owns its columns, it is still the table's 
>> job to manage them, not yours.
> 
> Agreed. I never liked the solution, which is one of the reasons why I posted 
> the message to begin with.
> 
>> Glad you got it solved anyway, but it's nice to know that the best solution 
>> turned out to be the correct, documented and recommended one after all!
> 
> Indeed. Learned stuff too...I had not fully understood the rules regarding 
> weak references before.
> 
> Hopefully this thread has helped others as well.


I was wondering why this was such a surprise to me, so I went hunting through 
sample code, books, etc.

I cannot seem to find any sample code, either in books (even Cocoa Programming 
for Mac OS X (3rd Edition)) or in Apple's own sample code where they follow 
these rules. I think that is why it has surprised me. I sure there must be some 
out there that do follow these rules, but the examples seem to be rare at the 
moment.

For a specific example, check out the AnimatedTableView sample code from Apple. 
 The ATColorTableController class is a datasource for the table, but it's 
dealloc looks like:

- (void)dealloc 
{
[_colorList release];
[_colorNames release];
[_window release];
[super dealloc];
}

Based on my current understanding, the dealloc should be setting it's 
datasource and delegate to nil. Correct? If so, I will file a bug.

Or, what is the reason why the code as written is correct?


___

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: Odd Crash when adding table columns manually

[Eric Gorr]

On Jan 19, 2011, at 8:19 PM, Graham Cox wrote:

> On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
> 
>> The table is also owned by the the scrolling view and therefore the window 
>> and would not be deallocated here...it will stick around long after the 
>> controller is deallocated.
> 
> You're right, but since the table owns its columns, it is still the table's 
> job to manage them, not yours.

Agreed. I never liked the solution, which is one of the reasons why I posted 
the message to begin with.

> Glad you got it solved anyway, but it's nice to know that the best solution 
> turned out to be the correct, documented and recommended one after all!

Indeed. Learned stuff too...I had not fully understood the rules regarding weak 
references before.

Hopefully this thread has helped others as 
well.___

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: Odd Crash when adding table columns manually

[Graham Cox]

On 20/01/2011, at 12:14 PM, Eric Gorr wrote:

> However, simply setting the the datasource and delegate to nil works as well 
> and is a better solution.

It is also the correct solution.


> The table is also owned by the the scrolling view and therefore the window 
> and would not be deallocated here...it will stick around long after the 
> controller is deallocated.

You're right, but since the table owns its columns, it is still the table's job 
to manage them, not yours.


Glad you got it solved anyway, but it's nice to know that the best solution 
turned out to be the correct, documented and recommended one after all!

--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: Odd Crash when adding table columns manually

[Eric Gorr]

The reason was that removing the table columns from the table prevented the 
crash from happening.

However, simply setting the the datasource and delegate to nil works as well 
and is a better solution.

Without any table columns, even though the table might have been marked as 
dirty, neither the datasource nor delegate was accessed.

The table is also owned by the the scrolling view and therefore the window and 
would not be deallocated here...it will stick around long after the controller 
is deallocated.

This is all easily demonstrated by downloading and playing with the sample 
project.


On Jan 19, 2011, at 7:35 PM, Graham Cox wrote:

> 
> On 20/01/2011, at 11:28 AM, Corbin Dunn wrote:
> 
>>  for ( column in tableColumns )
>>  {
>>  [table removeTableColumn:column];
>>  }
>>  
>>  [table release];
> 
> 
> Since the table owns its columns, why not just release the table - if it gets 
> deallocated the columns will go too. As you said this was the clean-up when 
> the window is deallocated, then the table WILL be deallocated here.
> 
> Is there some other reason you're going to these unnecessarily complicated 
> lengths?

___

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: Odd Crash when adding table columns manually

[Lee Ann Rucker]

On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:

> 
> In general, it is good practice in your apps to set your delegate and 
> datasource to nil. Who is to say something might cause a draw to happen, 
> which would then message your (now dealloced) delegate? Ideally, NSTableView 
> shouldn't message the delegate/datasource after the window is closed, but 
> something extra "setNeedsDisplay" messages get thrown into it, causing it to 
> happen, and crash. That is why your bug happened. 6728942 made an effort to 
> reduce the display message.
> 

If I'd set them in my code I would agree, but I expect that if it's set by the 
nib setup code then it should cleared by the nib cleanup 
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Odd Crash when adding table columns manually

[Graham Cox]

On 20/01/2011, at 11:28 AM, Corbin Dunn wrote:

>   for ( column in tableColumns )
>   {
>   [table removeTableColumn:column];
>   }
>   
>   [table release];


Since the table owns its columns, why not just release the table - if it gets 
deallocated the columns will go too. As you said this was the clean-up when the 
window is deallocated, then the table WILL be deallocated here.

Is there some other reason you're going to these unnecessarily complicated 
lengths?


--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: Odd Crash when adding table columns manually

[Corbin Dunn]

Hi eric,

As I mentioned earlier, it is good practice to set your delegate/ds to nil, 
since people inadvertently don't realize when they tell the table to redraw, 
and are 
surprised when they get the delegate messages after they are deallocd. I looked 
at your app, and I can point out the problem (I didn't run it, sorry):

- (void) dealloc
{
NSArray*tableColumns = [table tableColumns];
MyColumn*   column;

for ( column in tableColumns )
{
[table removeTableColumn:column];
}

[table release];

[super dealloc];
}

You are removing table columns, which the table marks that area as dirty, and 
redraws. Which calls your delegate/datasource (which is dealloced, clearly, 
since it is in dealloc)

That's what you are doing wrong in your code. It's okay to do it there as long 
as you realize what is happening...but I would recommend not doing it there , 
since it has side effects, and causes this problem you see.

Running instruments would point out the msg send was to your class.

corbin


On Jan 19, 2011, at 3:35 PM, Eric Gorr wrote:

> Hi Corbin,
> 
> I'm not using a custom cell. Just the standard text field one. I would assume 
> that it has implemented -copyWithZone correctly :-)
> 
> Feel free to check out the sample project, but I believe the correct answer 
> is to just set the datasource and delegate to nil as things are being 
> deallocated. The fact that I wasn't doing something I should be doing (?) is 
> what was causing it to crash.
> 
> Since it may  not have been clear, after pushing the button, which is when 
> the crash occurs, causes the modal event loop to end and everything to be 
> deallocated.

___

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: Odd Crash when adding table columns manually

[Corbin Dunn]

On Jan 19, 2011, at 12:28 PM, Eric Gorr wrote:

> I believe my situation is a bit different and my stack trace is not the same.
> 
> What I see in my stack trace is:
> 
> #00x978f8edb in objc_msgSend
> #10x00516f60 in ??
> #20x98fbb3ea in -[NSTableView preparedCellAtColumn:row:]
> #30x98fd58bc in -[NSTableView _drawContentsAtRow:column:withCellFrame:]
> #40x98fd492a in -[NSTableView drawRow:clipRect:]
> #50x98fd4362 in -[NSTableView drawRowIndexes:clipRect:]
> #60x98fd2d3b in -[NSTableView drawRect:]
> #70x98fc88fd in -[NSView _drawRect:clip:]
> #80x98fc5fc9 in -[NSView 
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #90x98fc695c in -[NSView 
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #10   0x98fc695c in -[NSView 
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #11   0x98fc695c in -[NSView 
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #12   0x98fc695c in -[NSView 
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #13   0x98fc555b in -[NSThemeFrame 
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> #14   0x98fc1ea2 in -[NSView 
> _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
> #15   0x98f22a57 in -[NSView displayIfNeeded]
> #16   0x98eebd40 in -[NSWindow displayIfNeeded]
> #17   0x98f1d28a in _handleWindowNeedsDisplay
> #18   0x92548e02 in __CFRunLoopDoObservers
> #19   0x92504d8d in __CFRunLoopRun
> #20   0x92504464 in CFRunLoopRunSpecific
> #21   0x92504291 in CFRunLoopRunInMode
> #22   0x96351f87 in RunCurrentEventLoopInMode
> #23   0x964d9ba1 in GetNextEventMatchingMask
> #24   0x964d9de9 in EventAvail
> #25   0x2183 in -[WindowTestAppDelegate applicationDidFinishLaunching:] 
> at WindowTestAppDelegate.m:92
> ...
> ...
> ...
> 
> However, if this is not a case where I should be setting the datasource and 
> delegate to nil, but instead is a bug, I would be interested...
> 
> My sample project will crash every time after the button is pushed.

Your probably not implementing -copyWithZone in your cell correctly (or at all).

Also, if you are crashing, use Instruments. Then after you have done that, you 
can ask why you get a zombie message. :). That's the first thing to do when you 
get a crash.

http://www.corbinstreehouse.com/blog/2007/10/instruments-on-leopard-how-to-debug-those-random-crashes-in-your-cocoa-app/

-corbin


___

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: Odd Crash when adding table columns manually

[Corbin Dunn]

On Jan 19, 2011, at 12:15 PM, Lee Ann Rucker wrote:

> Sounds like a radar bug I filed a while back. It was marked as a duplicate of 
> 6728942
> 
>> From my bug:
> 
> Snow leopard throws a doesNotRecognizeSelector in NSTableView.
> 
> Regression:
> Works on Leopard.
> 
> 6   com.apple.ExceptionHandling   0x976b1ebb -[NSExceptionHandler 
> _handleException:mask:] + 331
> 7   com.apple.ExceptionHandling   0x976b1d52 
> NSExceptionHandlerExceptionRaiser + 228
> 8   libobjc.A.dylib   0x916c2776 objc_exception_throw + 56
> 9   com.apple.CoreFoundation  0x9085072b -[NSObject(NSObject) 
> doesNotRecognizeSelector:] + 187
> 10  com.apple.CoreFoundation  0x907b5ae6 ___forwarding___ + 950
> 11  com.apple.CoreFoundation  0x907b56c2 _CF_forwarding_prep_0 + 50
> 12  com.apple.AppKit  0x95548f9d -[NSTableView 
> _dataSourceValueForColumn:row:] + 75
> 
> The dataSource and delegate are connected in nibs and never referenced in our 
> code, but we can work around this by setting them to nil explicitly when the 
> window is about to close, so we suspect that it's attempting to use 
> deallocated objects.


In general, it is good practice in your apps to set your delegate and 
datasource to nil. Who is to say something might cause a draw to happen, which 
would then message your (now dealloced) delegate? Ideally, NSTableView 
shouldn't message the delegate/datasource after the window is closed, but 
something extra "setNeedsDisplay" messages get thrown into it, causing it to 
happen, and crash. That is why your bug happened. 6728942 made an effort to 
reduce the display message.

--corbin



___

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: Odd Crash when adding table columns manually

[Eric Gorr]

I believe my situation is a bit different and my stack trace is not the same.

What I see in my stack trace is:

#0  0x978f8edb in objc_msgSend
#1  0x00516f60 in ??
#2  0x98fbb3ea in -[NSTableView preparedCellAtColumn:row:]
#3  0x98fd58bc in -[NSTableView _drawContentsAtRow:column:withCellFrame:]
#4  0x98fd492a in -[NSTableView drawRow:clipRect:]
#5  0x98fd4362 in -[NSTableView drawRowIndexes:clipRect:]
#6  0x98fd2d3b in -[NSTableView drawRect:]
#7  0x98fc88fd in -[NSView _drawRect:clip:]
#8  0x98fc5fc9 in -[NSView 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#9  0x98fc695c in -[NSView 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#10 0x98fc695c in -[NSView 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#11 0x98fc695c in -[NSView 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#12 0x98fc695c in -[NSView 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#13 0x98fc555b in -[NSThemeFrame 
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#14 0x98fc1ea2 in -[NSView 
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
#15 0x98f22a57 in -[NSView displayIfNeeded]
#16 0x98eebd40 in -[NSWindow displayIfNeeded]
#17 0x98f1d28a in _handleWindowNeedsDisplay
#18 0x92548e02 in __CFRunLoopDoObservers
#19 0x92504d8d in __CFRunLoopRun
#20 0x92504464 in CFRunLoopRunSpecific
#21 0x92504291 in CFRunLoopRunInMode
#22 0x96351f87 in RunCurrentEventLoopInMode
#23 0x964d9ba1 in GetNextEventMatchingMask
#24 0x964d9de9 in EventAvail
#25 0x2183 in -[WindowTestAppDelegate applicationDidFinishLaunching:] 
at WindowTestAppDelegate.m:92
...
...
...

However, if this is not a case where I should be setting the datasource and 
delegate to nil, but instead is a bug, I would be interested...

My sample project will crash every time after the button is pushed.


On Jan 19, 2011, at 3:15 PM, Lee Ann Rucker wrote:

> Sounds like a radar bug I filed a while back. It was marked as a duplicate of 
> 6728942
> 
> From my bug:
> 
> Snow leopard throws a doesNotRecognizeSelector in NSTableView.
> 
> Regression:
> Works on Leopard.
> 
> 6   com.apple.ExceptionHandling   0x976b1ebb -[NSExceptionHandler 
> _handleException:mask:] + 331
> 7   com.apple.ExceptionHandling   0x976b1d52 
> NSExceptionHandlerExceptionRaiser + 228
> 8   libobjc.A.dylib   0x916c2776 objc_exception_throw + 56
> 9   com.apple.CoreFoundation  0x9085072b -[NSObject(NSObject) 
> doesNotRecognizeSelector:] + 187
> 10  com.apple.CoreFoundation  0x907b5ae6 ___forwarding___ + 950
> 11  com.apple.CoreFoundation  0x907b56c2 _CF_forwarding_prep_0 + 50
> 12  com.apple.AppKit  0x95548f9d -[NSTableView 
> _dataSourceValueForColumn:row:] + 75
> 
> The dataSource and delegate are connected in nibs and never referenced in our 
> code, but we can work around this by setting them to nil explicitly when the 
> window is about to close, so we suspect that it's attempting to use 
> deallocated objects.
> 
> 
> On Jan 19, 2011, at 11:55 AM, Eric Gorr wrote:
> 
>> If anyone is interested, this odd crash turns out to be the same issue I was 
>> struggling with in the 'Window Controllers & Window Deallocation' ( 
>> http://bit.ly/gzd1LI ) thread.
>> 
>> If in the dealloc method of the table controller, I set the table's 
>> dataSource and delegate to nil, it will no longer crash. Instruments no 
>> longer reports any zombies. Upon a normal quit, Instruments does not report 
>> any leaks either.
>> 
>> Again, the documentation on Weak References can be found at:
>> 
>>  Memory Management Programming Guide - Weak References
>>  
>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/2043-1044135-BCICCFAE
>> 
>> Mike Ash has an interesting article on this topic as well:
>> 
>>   Zeroing Weak References in Objective-C 
>>   
>> http://www.mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html
>> 
>> 
>> 
>> On Jan 12, 2011, at 10:08 AM, Eric Gorr wrote:
>> 
>>> Try grabbing the project again - I have cleaned up a few things which 
>>> should make this a bit easier.
>>> 
>>> http://ericgorr.net/cocoadev/TableColumnTest.zip
>>> 
>>> It should crash everytime as long as in TableController.m the column are 
>>>

Re: Odd Crash when adding table columns manually

[Lee Ann Rucker]

Sounds like a radar bug I filed a while back. It was marked as a duplicate of 
6728942

>From my bug:

Snow leopard throws a doesNotRecognizeSelector in NSTableView.

Regression:
Works on Leopard.

6   com.apple.ExceptionHandling 0x976b1ebb -[NSExceptionHandler 
_handleException:mask:] + 331
7   com.apple.ExceptionHandling 0x976b1d52 
NSExceptionHandlerExceptionRaiser + 228
8   libobjc.A.dylib 0x916c2776 objc_exception_throw + 56
9   com.apple.CoreFoundation0x9085072b -[NSObject(NSObject) 
doesNotRecognizeSelector:] + 187
10  com.apple.CoreFoundation0x907b5ae6 ___forwarding___ + 950
11  com.apple.CoreFoundation0x907b56c2 _CF_forwarding_prep_0 + 50
12  com.apple.AppKit0x95548f9d -[NSTableView 
_dataSourceValueForColumn:row:] + 75

The dataSource and delegate are connected in nibs and never referenced in our 
code, but we can work around this by setting them to nil explicitly when the 
window is about to close, so we suspect that it's attempting to use deallocated 
objects.


On Jan 19, 2011, at 11:55 AM, Eric Gorr wrote:

> If anyone is interested, this odd crash turns out to be the same issue I was 
> struggling with in the 'Window Controllers & Window Deallocation' ( 
> http://bit.ly/gzd1LI ) thread.
> 
> If in the dealloc method of the table controller, I set the table's 
> dataSource and delegate to nil, it will no longer crash. Instruments no 
> longer reports any zombies. Upon a normal quit, Instruments does not report 
> any leaks either.
> 
> Again, the documentation on Weak References can be found at:
> 
>   Memory Management Programming Guide - Weak References
>   
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/2043-1044135-BCICCFAE
> 
> Mike Ash has an interesting article on this topic as well:
> 
>Zeroing Weak References in Objective-C 
>
> http://www.mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html
> 
> 
> 
> On Jan 12, 2011, at 10:08 AM, Eric Gorr wrote:
> 
>> Try grabbing the project again - I have cleaned up a few things which should 
>> make this a bit easier.
>> 
>> http://ericgorr.net/cocoadev/TableColumnTest.zip
>> 
>> It should crash everytime as long as in TableController.m the column are not 
>> being removed from the table first. You will have to go in an comment out 
>> that  line of code yourself.
>> 
>> I have also uploaded two screen recordings showing the crash.
>> 
>> http://ericgorr.net/cocoadev/TableColumnTestCrash01.m4v
>> http://ericgorr.net/cocoadev/TableColumnTestCrash02.m4v
>> 
>> The first movie is just using xcode & the debugger.
>> The second movie is running with zombies.
> 
>> 
> 
>>>>> Am 11.01.2011 um 18:06 schrieb Eric Gorr:
>>>>> 
>>>>>> I've got a sample test project at:
>>>>>> 
>>>>>> http://ericgorr.net/cocoadev/TableColumnTest.zip
>>>>>> 
>>>>>> which reproduces the strange crash.
>>>>>> 
>>>>>> I have a NSTableView to which I need to add NSTableColumns manually 
>>>>>> using the addTableColumn: method. The problem is that for some reason 
>>>>>> when I release the window and everything is being deallocated, someone 
>>>>>> has an extra retain on the table column and it sticks around. This 
>>>>>> causes a crash because the OS tries to redraw the table which really 
>>>>>> isn't there.
>>>>>> 
>>>>>> Note: With the code as written, it will only cause a crash 
>>>>>> sometimes...if you comment back in the call to the EventAvail function 
>>>>>> in WindowTestAppDelegate.m, it will crash every time...this is how I 
>>>>>> ended up finding the odd behavior to begin with - I am working with a 
>>>>>> cocoa/carbon app and EventAvail is still being called.
>>>>>> 
>>>>>> I can avoid the crash if, in my TableController class, I manually remove 
>>>>>> the table column from the table first. Is this what I am expected to do 
>>>>>> if I manually add the column? I would not have thought so, but perhaps I 
>>>>>> am wrong...?
>>>>>> 
>>>>>> In TableController.m, I have the function GetNewColumn which creates a 
>>>>>> new table column. After I alloc and init the column, I can log the 

Re: Odd Crash when adding table columns manually

[Eric Gorr]

If anyone is interested, this odd crash turns out to be the same issue I was 
struggling with in the 'Window Controllers & Window Deallocation' ( 
http://bit.ly/gzd1LI ) thread.

If in the dealloc method of the table controller, I set the table's dataSource 
and delegate to nil, it will no longer crash. Instruments no longer reports any 
zombies. Upon a normal quit, Instruments does not report any leaks either.

Again, the documentation on Weak References can be found at:

   Memory Management Programming Guide - Weak References
   
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/2043-1044135-BCICCFAE

Mike Ash has an interesting article on this topic as well:

Zeroing Weak References in Objective-C 

http://www.mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html



On Jan 12, 2011, at 10:08 AM, Eric Gorr wrote:

> Try grabbing the project again - I have cleaned up a few things which should 
> make this a bit easier.
> 
> http://ericgorr.net/cocoadev/TableColumnTest.zip
> 
> It should crash everytime as long as in TableController.m the column are not 
> being removed from the table first. You will have to go in an comment out 
> that  line of code yourself.
> 
> I have also uploaded two screen recordings showing the crash.
> 
> http://ericgorr.net/cocoadev/TableColumnTestCrash01.m4v
> http://ericgorr.net/cocoadev/TableColumnTestCrash02.m4v
> 
> The first movie is just using xcode & the debugger.
> The second movie is running with zombies.

> 

>>>> Am 11.01.2011 um 18:06 schrieb Eric Gorr:
>>>> 
>>>>> I've got a sample test project at:
>>>>> 
>>>>> http://ericgorr.net/cocoadev/TableColumnTest.zip
>>>>> 
>>>>> which reproduces the strange crash.
>>>>> 
>>>>> I have a NSTableView to which I need to add NSTableColumns manually using 
>>>>> the addTableColumn: method. The problem is that for some reason when I 
>>>>> release the window and everything is being deallocated, someone has an 
>>>>> extra retain on the table column and it sticks around. This causes a 
>>>>> crash because the OS tries to redraw the table which really isn't there.
>>>>> 
>>>>> Note: With the code as written, it will only cause a crash sometimes...if 
>>>>> you comment back in the call to the EventAvail function in 
>>>>> WindowTestAppDelegate.m, it will crash every time...this is how I ended 
>>>>> up finding the odd behavior to begin with - I am working with a 
>>>>> cocoa/carbon app and EventAvail is still being called.
>>>>> 
>>>>> I can avoid the crash if, in my TableController class, I manually remove 
>>>>> the table column from the table first. Is this what I am expected to do 
>>>>> if I manually add the column? I would not have thought so, but perhaps I 
>>>>> am wrong...?
>>>>> 
>>>>> In TableController.m, I have the function GetNewColumn which creates a 
>>>>> new table column. After I alloc and init the column, I can log the retain 
>>>>> count of the column and see that it is 1. After I call setWidth: on the 
>>>>> table column, I can see that the retain count is 2.
>>>>> 
>>>>> Can anyone shed some light on what might be going on here and why it is 
>>>>> crashing?
>>>>> 
>>>>> (if it matters, I am still running on 10.6.5)

___

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: Odd Crash when adding table columns manually

[Eric Gorr]

Try grabbing the project again - I have cleaned up a few things which should 
make this a bit easier.

http://ericgorr.net/cocoadev/TableColumnTest.zip

It should crash everytime as long as in TableController.m the column are not 
being removed from the table first. You will have to go in an comment out that  
line of code yourself.

I have also uploaded two screen recordings showing the crash.

http://ericgorr.net/cocoadev/TableColumnTestCrash01.m4v
http://ericgorr.net/cocoadev/TableColumnTestCrash02.m4v

The first movie is just using xcode & the debugger.
The second movie is running with zombies.



On Jan 12, 2011, at 9:52 AM, Keary Suska wrote:

> On Jan 11, 2011, at 5:49 PM, Eric Gorr wrote:
> 
>> I do release them after adding them to the table. It will still crash...
> 
> I cannot reproduce the crash with your test project. Have you verified, using 
> zombies, that in fact it is a table column crashing? It might have to do with 
> an invalid data source object...
> 
>> On Jan 11, 2011, at 7:29 PM, Peter Lübke  wrote:
>> 
>>> Table columns are retained by the table view they are added to.
>>> 
>>> So you can safely release or autorelease the table column right after 
>>> invoking -addTableColumn: .
>>> The table view owns its columns and will release them when it itself is 
>>> released.
>>> 
>>> This is the normal behaviour when adding subviews to an NSView or its 
>>> subclasses.
>>> 
>>> Peter
>>> 
>>> 
>>> Am 11.01.2011 um 18:06 schrieb Eric Gorr:
>>> 
 I've got a sample test project at:
 
 http://ericgorr.net/cocoadev/TableColumnTest.zip
 
 which reproduces the strange crash.
 
 I have a NSTableView to which I need to add NSTableColumns manually using 
 the addTableColumn: method. The problem is that for some reason when I 
 release the window and everything is being deallocated, someone has an 
 extra retain on the table column and it sticks around. This causes a crash 
 because the OS tries to redraw the table which really isn't there.
 
 Note: With the code as written, it will only cause a crash sometimes...if 
 you comment back in the call to the EventAvail function in 
 WindowTestAppDelegate.m, it will crash every time...this is how I ended up 
 finding the odd behavior to begin with - I am working with a cocoa/carbon 
 app and EventAvail is still being called.
 
 I can avoid the crash if, in my TableController class, I manually remove 
 the table column from the table first. Is this what I am expected to do if 
 I manually add the column? I would not have thought so, but perhaps I am 
 wrong...?
 
 In TableController.m, I have the function GetNewColumn which creates a new 
 table column. After I alloc and init the column, I can log the retain 
 count of the column and see that it is 1. After I call setWidth: on the 
 table column, I can see that the retain count is 2.
 
 Can anyone shed some light on what might be going on here and why it is 
 crashing?
 
 (if it matters, I am still running on 10.6.5)
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 

___

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: Odd Crash when adding table columns manually

[Keary Suska]

On Jan 11, 2011, at 5:49 PM, Eric Gorr wrote:

> I do release them after adding them to the table. It will still crash...

I cannot reproduce the crash with your test project. Have you verified, using 
zombies, that in fact it is a table column crashing? It might have to do with 
an invalid data source object...

> On Jan 11, 2011, at 7:29 PM, Peter Lübke  wrote:
> 
>> Table columns are retained by the table view they are added to.
>> 
>> So you can safely release or autorelease the table column right after 
>> invoking -addTableColumn: .
>> The table view owns its columns and will release them when it itself is 
>> released.
>> 
>> This is the normal behaviour when adding subviews to an NSView or its 
>> subclasses.
>> 
>> Peter
>> 
>> 
>> Am 11.01.2011 um 18:06 schrieb Eric Gorr:
>> 
>>> I've got a sample test project at:
>>> 
>>> http://ericgorr.net/cocoadev/TableColumnTest.zip
>>> 
>>> which reproduces the strange crash.
>>> 
>>> I have a NSTableView to which I need to add NSTableColumns manually using 
>>> the addTableColumn: method. The problem is that for some reason when I 
>>> release the window and everything is being deallocated, someone has an 
>>> extra retain on the table column and it sticks around. This causes a crash 
>>> because the OS tries to redraw the table which really isn't there.
>>> 
>>> Note: With the code as written, it will only cause a crash sometimes...if 
>>> you comment back in the call to the EventAvail function in 
>>> WindowTestAppDelegate.m, it will crash every time...this is how I ended up 
>>> finding the odd behavior to begin with - I am working with a cocoa/carbon 
>>> app and EventAvail is still being called.
>>> 
>>> I can avoid the crash if, in my TableController class, I manually remove 
>>> the table column from the table first. Is this what I am expected to do if 
>>> I manually add the column? I would not have thought so, but perhaps I am 
>>> wrong...?
>>> 
>>> In TableController.m, I have the function GetNewColumn which creates a new 
>>> table column. After I alloc and init the column, I can log the retain count 
>>> of the column and see that it is 1. After I call setWidth: on the table 
>>> column, I can see that the retain count is 2.
>>> 
>>> Can anyone shed some light on what might be going on here and why it is 
>>> crashing?
>>> 
>>> (if it matters, I am still running on 10.6.5)

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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: Odd Crash when adding table columns manually

[Eric Gorr]

I do release them after adding them to the table. It will still crash...

Sent from my iPad

On Jan 11, 2011, at 7:29 PM, Peter Lübke  wrote:

> Table columns are retained by the table view they are added to.
> 
> So you can safely release or autorelease the table column right after 
> invoking -addTableColumn: .
> The table view owns its columns and will release them when it itself is 
> released.
> 
> This is the normal behaviour when adding subviews to an NSView or its 
> subclasses.
> 
> Peter
> 
> 
> Am 11.01.2011 um 18:06 schrieb Eric Gorr:
> 
>> I've got a sample test project at:
>> 
>> http://ericgorr.net/cocoadev/TableColumnTest.zip
>> 
>> which reproduces the strange crash.
>> 
>> I have a NSTableView to which I need to add NSTableColumns manually using 
>> the addTableColumn: method. The problem is that for some reason when I 
>> release the window and everything is being deallocated, someone has an extra 
>> retain on the table column and it sticks around. This causes a crash because 
>> the OS tries to redraw the table which really isn't there.
>> 
>> Note: With the code as written, it will only cause a crash sometimes...if 
>> you comment back in the call to the EventAvail function in 
>> WindowTestAppDelegate.m, it will crash every time...this is how I ended up 
>> finding the odd behavior to begin with - I am working with a cocoa/carbon 
>> app and EventAvail is still being called.
>> 
>> I can avoid the crash if, in my TableController class, I manually remove the 
>> table column from the table first. Is this what I am expected to do if I 
>> manually add the column? I would not have thought so, but perhaps I am 
>> wrong...?
>> 
>> In TableController.m, I have the function GetNewColumn which creates a new 
>> table column. After I alloc and init the column, I can log the retain count 
>> of the column and see that it is 1. After I call setWidth: on the table 
>> column, I can see that the retain count is 2.
>> 
>> Can anyone shed some light on what might be going on here and why it is 
>> crashing?
>> 
>> (if it matters, I am still running on 10.6.5)
>> 
> 
___

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: Odd Crash when adding table columns manually

[Peter Lübke]

Table columns are retained by the table view they are added to.

So you can safely release or autorelease the table column right after  
invoking -addTableColumn: .
The table view owns its columns and will release them when it itself  
is released.


This is the normal behaviour when adding subviews to an NSView or its  
subclasses.


Peter


Am 11.01.2011 um 18:06 schrieb Eric Gorr:


I've got a sample test project at:

http://ericgorr.net/cocoadev/TableColumnTest.zip

which reproduces the strange crash.

I have a NSTableView to which I need to add NSTableColumns manually  
using the addTableColumn: method. The problem is that for some  
reason when I release the window and everything is being  
deallocated, someone has an extra retain on the table column and it  
sticks around. This causes a crash because the OS tries to redraw  
the table which really isn't there.


Note: With the code as written, it will only cause a crash  
sometimes...if you comment back in the call to the EventAvail  
function in WindowTestAppDelegate.m, it will crash every  
time...this is how I ended up finding the odd behavior to begin  
with - I am working with a cocoa/carbon app and EventAvail is still  
being called.


I can avoid the crash if, in my TableController class, I manually  
remove the table column from the table first. Is this what I am  
expected to do if I manually add the column? I would not have  
thought so, but perhaps I am wrong...?


In TableController.m, I have the function GetNewColumn which  
creates a new table column. After I alloc and init the column, I  
can log the retain count of the column and see that it is 1. After  
I call setWidth: on the table column, I can see that the retain  
count is 2.


Can anyone shed some light on what might be going on here and why  
it is crashing?


(if it matters, I am still running on 10.6.5)



___

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

Odd Crash when adding table columns manually

[Eric Gorr]

I've got a sample test project at:

http://ericgorr.net/cocoadev/TableColumnTest.zip

which reproduces the strange crash.

I have a NSTableView to which I need to add NSTableColumns manually using the 
addTableColumn: method. The problem is that for some reason when I release the 
window and everything is being deallocated, someone has an extra retain on the 
table column and it sticks around. This causes a crash because the OS tries to 
redraw the table which really isn't there.

Note: With the code as written, it will only cause a crash sometimes...if you 
comment back in the call to the EventAvail function in WindowTestAppDelegate.m, 
it will crash every time...this is how I ended up finding the odd behavior to 
begin with - I am working with a cocoa/carbon app and EventAvail is still being 
called. 

I can avoid the crash if, in my TableController class, I manually remove the 
table column from the table first. Is this what I am expected to do if I 
manually add the column? I would not have thought so, but perhaps I am wrong...?

In TableController.m, I have the function GetNewColumn which creates a new 
table column. After I alloc and init the column, I can log the retain count of 
the column and see that it is 1. After I call setWidth: on the table column, I 
can see that the retain count is 2.

Can anyone shed some light on what might be going on here and why it is 
crashing?

(if it matters, I am still running on 10.6.5)



___

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: Odd crash

[Steve Shepard]

I've seen this too. Customer comments in the crash report indicate
that it occurs most frequently when saving to a USB "thumb" drive. It
only seems to happen on 10.6.2.

-Steve

On Mon, Mar 22, 2010 at 1:48 PM, Martin Wierschin  wrote:
>>> Thread 6 Crashed:  Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue
>>> 0   com.apple.DesktopServices           0x901d8445
>>> TFSVolumeInfo::GetVolumeSyncThread() + 83
>>> 1   com.apple.DesktopServices           0x901d8391
>>> TNode::PostNodeTaskRequest(TCountedPtr const&) const + 81
>
> I've seen these kinds of crashes from users as well. A recent crash log
> that's slightly different:
>
>> Thread 12 Crashed:  Dispatch queue: TFSVolumeInfo::GetSizingGCDQueue
>> 0   com.apple.DesktopServices           0x96dad066
>> TFSInfo::AddPtrReference() + 6
>> 1   com.apple.DesktopServices           0x96dae1b6 TNode::IsContainer()
>> const + 30
>> 2   com.apple.DesktopServices           0x96dbae53
>> TNode::PostFolderSizingTaskRequest(TCountedPtr const&, bool)
>> const + 39
>> 3   com.apple.DesktopServices           0x96dda660
>> TNode::DispatchResizeRequestNow(TNodeTask*) + 122
>> 4   com.apple.DesktopServices           0x96dda5d8
>> __SetTimerToDispatchResizeRequest_block_invoke_1 + 32
>
> ~Martin
>
> ___
>
> 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/steveshep%40gmail.com
>
> This email sent to steves...@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

Re: Odd crash

[Martin Wierschin]

Thread 6 Crashed:  Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue
0   com.apple.DesktopServices   0x901d8445  
TFSVolumeInfo::GetVolumeSyncThread() + 83
1   com.apple.DesktopServices   0x901d8391  
TNode::PostNodeTaskRequest(TCountedPtr const&) const + 81


I've seen these kinds of crashes from users as well. A recent crash  
log that's slightly different:



Thread 12 Crashed:  Dispatch queue: TFSVolumeInfo::GetSizingGCDQueue
0   com.apple.DesktopServices 	0x96dad066  
TFSInfo::AddPtrReference() + 6
1   com.apple.DesktopServices 	0x96dae1b6 TNode::IsContainer()  
const + 30
2   com.apple.DesktopServices 	0x96dbae53  
TNode::PostFolderSizingTaskRequest(TCountedPtr const&,  
bool) const + 39
3   com.apple.DesktopServices 	0x96dda660  
TNode::DispatchResizeRequestNow(TNodeTask*) + 122
4   com.apple.DesktopServices 	0x96dda5d8  
__SetTimerToDispatchResizeRequest_block_invoke_1 + 32


~Martin

___

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: Odd crash

[Gideon King]

Ah, I've been seeing a bunch of TNode errors too - I thought it must be 
something I was doing wrong. Could never work out any rhyme or reason to it, or 
reproduce it here, but received quite a few reports of crashes due to this from 
customers. Glad to know I'm not going crazy.

Gideon___

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: Odd crash

[Paul Sanders]

And I have seen something similar (including once here), always, I see, on 
10.6.2:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0018
Crashed Thread:  2

...

Thread 2 Crashed:
0   com.apple.DesktopServices 0x9873dd1b 
TNode::FSVolumeObserverCallback(short, __CFString const*, void const*, void*) + 
1069
1   ...ple.CoreServices.CarbonCore 0x918be381 _FSVolumeObserverCallback + 
214
2   com.apple.CoreFoundation  0x91ca7b72 __CFMachPortPerform + 338
3   com.apple.CoreFoundation  0x91ca38db __CFRunLoopRun + 6523
4   com.apple.CoreFoundation  0x91ca1864 CFRunLoopRunSpecific + 452
5   com.apple.CoreFoundation  0x91ca77a4 CFRunLoopRun + 84
6   com.apple.DesktopServices 0x986e363f 
TSystemNotificationTask::SystemNotificationTaskProc(void*) + 643
7   ...ple.CoreServices.CarbonCore 0x918d87ae PrivateMPEntryPoint + 68
8   libSystem.B.dylib 0x922f4fbd _pthread_start + 345
9   libSystem.B.dylib 0x922f4e42 thread_start + 34

I have submitted a bug report (#7753826).

Paul Sanders.

- Original Message - 
From: "Kevin Wojniak" 
To: "Kyle Sluder" 
Cc: "Cocoa-Dev List" 
Sent: Monday, March 22, 2010 3:31 PM
Subject: Re: Odd crash


I've seen this crash plenty of times as well. Hopefully it'll be fixed in 
10.6.3.
___

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: Odd crash

[Kevin Wojniak]

I've seen this crash plenty of times as well. Hopefully it'll be fixed in 
10.6.3.


On Mar 21, 2010, at 4:40 PM, Kyle Sluder wrote:

> On Sun, Mar 21, 2010 at 3:37 PM, Graham Cox  wrote:
>> I got this crash report from a user. It seems to be an isolated incident but 
>> it would be good to know what sort of problem this indicates so if it crops 
>> up again I know where to look for it. I've never seen this code before and 
>> it is in Thread 6 - my app doesn't do much with threads so I'm guessing it's 
>> something Cocoa is doing, maybe with the disk by the look of it. Any ideas?
>> 
>> Thread 6 Crashed:  Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue
>> 0   com.apple.DesktopServices   0x901d8445 
>> TFSVolumeInfo::GetVolumeSyncThread() + 83
>> 1   com.apple.DesktopServices   0x901d8391 
>> TNode::PostNodeTaskRequest(TCountedPtr const&) const + 81
> 
> TNode and TFSVolumeInfo have been the source of many crashes since
> 10.6 debuted. Usually it involves the open panel. All you can probably
> do is file a bug.
> 
> --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/kainjow%40kainjow.com
> 
> This email sent to kain...@kainjow.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

Re: Odd crash

[Kyle Sluder]

On Sun, Mar 21, 2010 at 3:37 PM, Graham Cox  wrote:
> I got this crash report from a user. It seems to be an isolated incident but 
> it would be good to know what sort of problem this indicates so if it crops 
> up again I know where to look for it. I've never seen this code before and it 
> is in Thread 6 - my app doesn't do much with threads so I'm guessing it's 
> something Cocoa is doing, maybe with the disk by the look of it. Any ideas?
>
> Thread 6 Crashed:  Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue
> 0   com.apple.DesktopServices           0x901d8445 
> TFSVolumeInfo::GetVolumeSyncThread() + 83
> 1   com.apple.DesktopServices           0x901d8391 
> TNode::PostNodeTaskRequest(TCountedPtr const&) const + 81

TNode and TFSVolumeInfo have been the source of many crashes since
10.6 debuted. Usually it involves the open panel. All you can probably
do is file a bug.

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

Odd crash

[Graham Cox]

I got this crash report from a user. It seems to be an isolated incident but it 
would be good to know what sort of problem this indicates so if it crops up 
again I know where to look for it. I've never seen this code before and it is 
in Thread 6 - my app doesn't do much with threads so I'm guessing it's 
something Cocoa is doing, maybe with the disk by the look of it. Any ideas?

Thread 6 Crashed:  Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue
0   com.apple.DesktopServices   0x901d8445 
TFSVolumeInfo::GetVolumeSyncThread() + 83
1   com.apple.DesktopServices   0x901d8391 
TNode::PostNodeTaskRequest(TCountedPtr const&) const + 81
2   com.apple.DesktopServices   0x901d80fa 
TNode::RequestInternalTask(unsigned long, TPropertyValue const&) const + 172
3   com.apple.DesktopServices   0x901dd672 
TNode::RequestSynchronize(unsigned long) + 120
4   com.apple.DesktopServices   0x90226359 
TNode::SynchronizeVolumes(bool, TCountedPtr const&) + 431
5   com.apple.DesktopServices   0x9022a806 TNode::HandleChange(char*, 
unsigned long, TCountedPtr const&) + 1746
6   com.apple.DesktopServices   0x90226011 
TNode::AddVolume(TCountedPtr const&, short, unsigned long, 
TNodePtr&, bool) + 1175
7   com.apple.DesktopServices   0x901d20ea TNode::GetVolume(short, 
unsigned long, bool) + 382
8   com.apple.DesktopServices   0x901d54b8 
TNode::GetNodeFromFSInfo(TCountedPtr const&, TNodePtr&, unsigned long, 
bool) + 416
9   com.apple.DesktopServices   0x901f4464 
TNode::ResolveSharedFileListAliasIfNeeded() + 714
10  com.apple.DesktopServices   0x901dbcc9 
TNode::SynchronizeChildren(unsigned long, TNodeEventPtrSet&) + 4409
11  com.apple.DesktopServices   0x901da6b0 TNode::HandleSync(unsigned 
long) + 886
12  com.apple.DesktopServices   0x901da306 
TNode::HandleSync(TCountedPtr const&, TNodePtr const&) + 56
13  com.apple.DesktopServices   0x9022d0c4 
TNode::HandleNodeRequest(TCountedPtr const&, 
TCountedPtr const&) + 1154
14  com.apple.DesktopServices   0x901d878f 
__PostNodeTaskRequest_block_invoke_2 + 94
15  libSystem.B.dylib   0x9544b828 
_dispatch_call_block_and_release + 16
16  libSystem.B.dylib   0x9543e1f4 _dispatch_queue_drain + 249
17  libSystem.B.dylib   0x9543dc52 _dispatch_queue_invoke + 50
18  libSystem.B.dylib   0x9543da68 _dispatch_worker_thread2 + 
234
19  libSystem.B.dylib   0x9543d4f1 _pthread_wqthread + 390
20  libSystem.B.dylib   0x9543d336 start_wqthread + 30



--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: Odd crash only when Toast running

[Ken Ferry]

On Tue, Jun 2, 2009 at 7:57 AM, Shawn Erickson  wrote:

> On Tue, Jun 2, 2009 at 12:12 AM, Graham Cox 
> wrote:
> >
> > On 02/06/2009, at 4:23 PM, Trygve Inda wrote:
>
> >> The file that this image comes from will be deleted later on, but once
> >> initWithContentsOfFile is called, I assume it no longer needs the file,
> >> right?
>
> No it might still need the file. NSImage is often lazy about what it
> does so as to not waste resources until they are needed. Can you
> outline what you are doing with the file after you create the NSImage
> instance? Are you writing to it again, etc.?


This is the difference between -initByReferencingURL: and
-initWithContentsOfURL:.

The "contents" methods non-lazily suck the data in from disk and
disassociate from the file.

The "referencing" methods, on the other hand, treat the in-memory
representation as a cache for the file on disk.  When you use this method,
you promise that the file on disk is not going anywhere or changing.  It's
easy to make this promise for files that are in your app's bundle and are
used for its UI.  +[NSImage imageNamed:] uses -initByReferencingURL:.

-initByReferencingURL: does no IO.

-Ken
Cocoa Frameworks
___

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: Odd crash only when Toast running

[Bill Bumgarner]

On Jun 2, 2009, at 9:32 AM, Trygve Inda wrote:

+com.DivXInc.DivXDecoder 6.4.0


I would be suspect of that particular component.

Plugging com.DivXInc.DivXDecoder yields a Mac OS X crash report as the  
first hit. :)


Seriously, though, if that particular plugin is trying to unload  
itself or anything else, it could cause a mysterious crash of the  
nature you are seeing.


b.bum

___

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: Odd crash only when Toast running

[Trygve Inda]

> On Tue, Jun 2, 2009 at 12:12 AM, Graham Cox  wrote:
>> 
>> On 02/06/2009, at 4:23 PM, Trygve Inda wrote:
> 
>>> The only thing I can find that may be related (based on [NSWindow
>>> displayIfNeeded] being in the report) is that my app has a single window
>>> with a single view and I call:
>>> 
>>> NSImage*    theImage = [[[NSImage alloc]
>>> initWithContentsOfFile:mapImagePath] autorelease];
>>> 
>>> [window orderFront:self];
>> 
>> You could try doing this step first, before alloc/init the image. I'm
>> wondering if this is causing a drain of the autorelease pool.
> 
> It can't cause the autorelease pool related to the current method to
> be draining.
> 
>>> [imageView setImage:theImage];
>>> [imageView setNeedsDisplay:YES];
>>> 
>>> The file that this image comes from will be deleted later on, but once
>>> initWithContentsOfFile is called, I assume it no longer needs the file,
>>> right?
> 
> No it might still need the file. NSImage is often lazy about what it
> does so as to not waste resources until they are needed. Can you
> outline what you are doing with the file after you create the NSImage
> instance? Are you writing to it again, etc.?
> 
> As a test I would try sending an -isValid message to the image
> instance (think isValid is the correct name) after creating it.

I am loading an image form disk, assigning it to an ImageView and then later
the file will be deleted, a new one created (different file name) and the
new one will be assigned to the image. The delete/replace is at least a
minute between intervals and I call setNeedsDisplay right away so I don't
think it is trying to poll the file later.

Trygev


___

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: Odd crash only when Toast running

[Trygve Inda]

>   And if you do find an unknown library in the list that proves
> tone problematic, please file a bug describing the issue and including
> the crash log.
> 
> b.bum

The only non-Apple ones are:

+org.andymatuschak.Sparkle 1.5 Beta 6
+com.DivXInc.DivXDecoder 6.4.0

Sparkle is used in my app, but DivXDecoder is foreign. I don't have Toast
here so I am only going off of what a user says.

Trygve


___

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: Odd crash only when Toast running

[Shawn Erickson]

2009/6/1 Trygve Inda :

> Thoughts?
>
> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x2c1f3000
> Crashed Thread:  0
>
> Thread 0 Crashed:
> com.apple.CoreGraphics    0x90afbac0 CGSConvertBGR888toRGBA + 160
> com.apple.CoreGraphics    0x90a5494b argb32_image + 5611

Out of curiosity...

Do you have the full crash log? If so at the bottom in the image
section do you see any entries that appear to be from Toast or other
3rd party software? If this was a crash from a Leopard system look for
a "+" before the bundle name of the library, those are 3rd party (aka
not provided by Apple).

-Shawn
___

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: Odd crash only when Toast running

[Shawn Erickson]

On Tue, Jun 2, 2009 at 12:12 AM, Graham Cox  wrote:
>
> On 02/06/2009, at 4:23 PM, Trygve Inda wrote:

>> The only thing I can find that may be related (based on [NSWindow
>> displayIfNeeded] being in the report) is that my app has a single window
>> with a single view and I call:
>>
>> NSImage*    theImage = [[[NSImage alloc]
>> initWithContentsOfFile:mapImagePath] autorelease];
>>
>> [window orderFront:self];
>
> You could try doing this step first, before alloc/init the image. I'm
> wondering if this is causing a drain of the autorelease pool.

It can't cause the autorelease pool related to the current method to
be draining.

>> [imageView setImage:theImage];
>> [imageView setNeedsDisplay:YES];
>>
>> The file that this image comes from will be deleted later on, but once
>> initWithContentsOfFile is called, I assume it no longer needs the file,
>> right?

No it might still need the file. NSImage is often lazy about what it
does so as to not waste resources until they are needed. Can you
outline what you are doing with the file after you create the NSImage
instance? Are you writing to it again, etc.?

As a test I would try sending an -isValid message to the image
instance (think isValid is the correct name) after creating it.

>> I assume the autorelease is ok since theImage will be retained by
>> imageView.
>
> Yes, unless it was autoreleased before that step was invoked, in which case
>  will be stale which could be crashing the RIP internals.

His code example shows no management of an autorelease pool here so...

> Why not just -release the image after calling setImage, rather than
> autoreleasing?

It is a fairly common Cocoa programming pattern to do the allocation,
init, and memory management all in a single line. Helps avoid a
missing a later release because omission or logic flow error.

-Shawn
___

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: Odd crash only when Toast running

[Graham Cox]

On 02/06/2009, at 4:23 PM, Trygve Inda wrote:

I have a user reporting an odd crash that I can't make happen here,  
nor has
anyone else reported this, but the report is consistent and happens  
only
when Toast is running. It seems very deep in the OS and as far as I  
know, I

am not using libRIP.A.dylib.


Yes you are - RIP stands for "raster image processing", in other  
words, any drawing.



The only thing I can find that may be related (based on [NSWindow
displayIfNeeded] being in the report) is that my app has a single  
window

with a single view and I call:

NSImage*theImage = [[[NSImage alloc]
initWithContentsOfFile:mapImagePath] autorelease];

[window orderFront:self];


You could try doing this step first, before alloc/init the image. I'm  
wondering if this is causing a drain of the autorelease pool.



[imageView setImage:theImage];
[imageView setNeedsDisplay:YES];

The file that this image comes from will be deleted later on, but once
initWithContentsOfFile is called, I assume it no longer needs the  
file,

right?

I assume the autorelease is ok since theImage will be retained by  
imageView.


Yes, unless it was autoreleased before that step was invoked, in which  
case  will be stale which could be crashing the RIP internals.


Why not just -release the image after calling setImage, rather than  
autoreleasing?


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

Odd crash only when Toast running

[Trygve Inda]

I have a user reporting an odd crash that I can't make happen here, nor has
anyone else reported this, but the report is consistent and happens only
when Toast is running. It seems very deep in the OS and as far as I know, I
am not using libRIP.A.dylib.

The only thing I can find that may be related (based on [NSWindow
displayIfNeeded] being in the report) is that my app has a single window
with a single view and I call:

NSImage*theImage = [[[NSImage alloc]
initWithContentsOfFile:mapImagePath] autorelease];

[window orderFront:self];
[imageView setImage:theImage];
[imageView setNeedsDisplay:YES];

The file that this image comes from will be deleted later on, but once
initWithContentsOfFile is called, I assume it no longer needs the file,
right?

I assume the autorelease is ok since theImage will be retained by imageView.

Thoughts?

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x2c1f3000
Crashed Thread:  0

Thread 0 Crashed:
com.apple.CoreGraphics0x90afbac0 CGSConvertBGR888toRGBA + 160
com.apple.CoreGraphics0x90a5494b argb32_image + 5611
libRIP.A.dylib0x95e476f9 ripd_Mark + 326
libRIP.A.dylib0x95e41977 ripl_BltImage + 1307
libRIP.A.dylib0x95e2b549 ripc_RenderImage + 273
libRIP.A.dylib0x95e3be6a ripc_DrawImage + 5102
com.apple.CoreGraphics0x90a4732d CGContextDrawImage + 397
com.apple.AppKit  0x968004b0 -[NSBitmapImageRep
_drawFromRect:toRect:operation:alpha:compositing:flipped:ignoreContext:] +
2621
com.apple.AppKit  0x967ff70b -[NSImage
drawInRect:fromRect:operation:fraction:] + 5109
com.apple.AppKit  0x96c44d2a -[NSImage
_drawMappingAlignmentRectToRect:withState:backgroundStyle:operation:fractio
:flip:] + 1041
com.apple.AppKit 0x9689c21b -[NSImageCell
drawInteriorWithFrame:inView:] +
751
com.apple.AppKit 0x9689bf1f -[NSImageCell drawWithFrame:inView:]
+ 2230
com.apple.AppKit 0x967df4a7 -[NSControl drawRect:] + 378
com.apple.AppKit 0x9687322c -[NSView _drawRect:clip:] + 3853
com.apple.AppKit 0x96871d23 -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1050
com.apple.AppKit 0x968720ba -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1969
16  com.apple.AppKit 0x968720ba -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1969
17  com.apple.AppKit 0x96870679 -[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRect
ForView:topView:] + 759
18  com.apple.AppKit 0x96958929 -[NSNextStepFrame
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRect
ForView:topView:] + 340
19  com.apple.AppKit 0x9686cadf -[NSView
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3090
20  com.apple.AppKit 0x967ad4b3 -[NSView displayIfNeeded] + 933
21  com.apple.AppKit 0x967ad061 -[NSWindow displayIfNeeded] + 189
22  com.apple.AppKit 0x967ace84 _handleWindowNeedsDisplay + 436
23  com.apple.CoreFoundation 0x9603c942 __CFRunLoopDoObservers + 466
24  com.apple.CoreFoundation 0x9603dc9c CFRunLoopRunSpecific + 844
25  com.apple.CoreFoundation 0x9603ec78 CFRunLoopRunInMode + 88
26  com.apple.HIToolbox  0x94ec628c RunCurrentEventLoopInMode + 283
27  com.apple.HIToolbox  0x94ec60a5 ReceiveNextEventCommon + 374
28  com.apple.HIToolbox  0x94ec5f19
BlockUntilNextEventMatchingListInMode+106
29  com.apple.AppKit 0x967aad0d _DPSNextEvent + 657
30  com.apple.AppKit 0x967aa5c0 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
31  com.apple.AppKit 0x967a35fb -[NSApplication run] + 795
32  com.apple.AppKit 0x96770834 NSApplicationMain + 574
33  com.myApplication0x2a80 main + 30
34  com.myApplication0x2a36 start + 54


___

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: Odd crash-loading AppleScripts

[Reza Farhad]

Reported the bug to Apple.
Reza

On 5 Mar 2009, at 12:00, Matt Gough wrote:


Reza,

I suspect this is not your fault. I suggest you file a radar bug.

BTW - You never release NSAppleScript *script, so this code would  
leak.


and your spelling is as bad as ever  :) 'laodRunScript'

Matt


On 5 Mar 2009, at 11:25, Reza Farhad wrote:


Has

Thanks for your suggestion but it did not make any difference.
To make sure that there was nothing else in my code that was  
creating the issue I made a little app to reproduce the problem.  
This app Loads a simple "Hello World" script and displays it in a  
window. Again if I have Guard Malloc on, it would crash the app,  
but otherwise it seems to work. Here is a link to the test project  
app, so others can have a look and see if they can get to the  
bottom of this.


http://www.Qu-s.eu/Dev/AppleScriptLoader.zip

Thanks
Reza

On 4 Mar 2009, at 19:27, has wrote:




___

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: Odd crash-loading AppleScripts

[Reza Farhad]

Matt

I thought this could be some issue beyond my control.
I agree with the leak, which in the real project  would be handled.
About the spelling no comment

Reza

On 5 Mar 2009, at 12:00, Matt Gough wrote:


Reza,

I suspect this is not your fault. I suggest you file a radar bug.

BTW - You never release NSAppleScript *script, so this code would  
leak.


and your spelling is as bad as ever  :) 'laodRunScript'

Matt


On 5 Mar 2009, at 11:25, Reza Farhad wrote:


Has

Thanks for your suggestion but it did not make any difference.
To make sure that there was nothing else in my code that was  
creating the issue I made a little app to reproduce the problem.  
This app Loads a simple "Hello World" script and displays it in a  
window. Again if I have Guard Malloc on, it would crash the app,  
but otherwise it seems to work. Here is a link to the test project  
app, so others can have a look and see if they can get to the  
bottom of this.


http://www.Qu-s.eu/Dev/AppleScriptLoader.zip

Thanks
Reza

On 4 Mar 2009, at 19:27, has wrote:




___

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: Odd crash-loading AppleScripts

[matt . gough]

In fact, even this simpler version will trip up GuardMalloc


-( void ) laodRunScript
{
NSDictionary*errors = nil;
NSString*fieldContent = @"Could not Load Script, See 
Logs";
	NSAppleScript   *script = [[ NSAppleScript alloc ]  
initWithSource:@"return \"Hello World\""];

if ( script ){
NSAppleEventDescriptor* returnDescriptor = nil;
returnDescriptor = [ script executeAndReturnError: &errors ];
if ( !errors ){
			fieldContent = [ NSString stringWithFormat:@"Message from script:  
%@", [ returnDescriptor stringValue ]];

}
else{
NSLog( @"there was an error loading the script:%@", 
errors );
}
[script release];
}
else{
NSLog( @"there was an error loading the script:%@", errors );
}

[ textField_m setStringValue:fieldContent ];
}   

On 5 Mar 2009, at 13:00, matt.go...@agfa.com wrote:


Reza,

I suspect this is not your fault. I suggest you file a radar bug.

BTW - You never release NSAppleScript *script, so this code would  
leak.


and your spelling is as bad as ever  :) 'laodRunScript'

Matt


On 5 Mar 2009, at 11:25, Reza Farhad wrote:


Has

Thanks for your suggestion but it did not make any difference.
To make sure that there was nothing else in my code that was  
creating the issue I made a little app to reproduce the problem.  
This app Loads a simple "Hello World" script and displays it in a  
window. Again if I have Guard Malloc on, it would crash the app,  
but otherwise it seems to work. Here is a link to the test project  
app, so others can have a look and see if they can get to the  
bottom of this.


http://www.Qu-s.eu/Dev/AppleScriptLoader.zip

Thanks
Reza

On 4 Mar 2009, at 19:27, has wrote:


___

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/matt.gough%40agfa.com

This email sent to matt.go...@agfa.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

Re: Odd crash-loading AppleScripts

[Matt Gough]

Reza,

I suspect this is not your fault. I suggest you file a radar bug.

BTW - You never release NSAppleScript *script, so this code would leak.

and your spelling is as bad as ever  :) 'laodRunScript'

Matt


On 5 Mar 2009, at 11:25, Reza Farhad wrote:


Has

Thanks for your suggestion but it did not make any difference.
To make sure that there was nothing else in my code that was  
creating the issue I made a little app to reproduce the problem.  
This app Loads a simple "Hello World" script and displays it in a  
window. Again if I have Guard Malloc on, it would crash the app, but  
otherwise it seems to work. Here is a link to the test project app,  
so others can have a look and see if they can get to the bottom of  
this.


http://www.Qu-s.eu/Dev/AppleScriptLoader.zip

Thanks
Reza

On 4 Mar 2009, at 19:27, has wrote:


___

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

Odd crash-loading AppleScripts

[Reza Farhad]

Has

Thanks for your suggestion but it did not make any difference.
To make sure that there was nothing else in my code that was creating  
the issue I made a little app to reproduce the problem. This app Loads  
a simple "Hello World" script and displays it in a window. Again if I  
have Guard Malloc on, it would crash the app, but otherwise it seems  
to work. Here is a link to the test project app, so others can have a  
look and see if they can get to the bottom of this.


http://www.Qu-s.eu/Dev/AppleScriptLoader.zip

Thanks
Reza

On 4 Mar 2009, at 19:27, has wrote:


Reza Farhad wrote:


Paul

I switched on Guard Malloc from the Run Menu in Xcode

It appears that I am getting the crash for a call that is trying to
load an AppleScript.

NSDictionary*errors = [ NSDictionary dictionary ];
NSAppleScript   *script = [[ NSAppleScript alloc ]
initWithContentsOfURL:url error:&errors ];



One point, which may or may not be related: as with **NSError  
arguments, you do not need to allocate an NSDictionary instance  
yourself. If there is an error to report,  
initWithContentsOfURL:error: will create it for you.


HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.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

Re: Odd crash

[has]

Reza Farhad wrote:


Paul

I switched on Guard Malloc from the Run Menu in Xcode

It appears that I am getting the crash for a call that is trying to
load an AppleScript.

NSDictionary*errors = [ NSDictionary dictionary ];
NSAppleScript   *script = [[ NSAppleScript alloc ]
initWithContentsOfURL:url error:&errors ];



One point, which may or may not be related: as with **NSError  
arguments, you do not need to allocate an NSDictionary instance  
yourself. If there is an error to report, initWithContentsOfURL:error:  
will create it for you.


HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.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

Re: Odd crash

[Sean McBride]

On 3/4/09 3:36 PM, Reza Farhad said:

>Also is it a bad idea to leave MallocStackLogging,
>MallocStackLoggingNoCompact, MallocScribble in the release version.

They are environment variables, so do not affect the compilation/linking
of your app.  You can and should test both your debug and release builds
with these variables.

--

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: Odd crash

[Reza Farhad]

Paul

I switched on Guard Malloc from the Run Menu in Xcode

It appears that I am getting the crash for a call that is trying to  
load an AppleScript.


NSDictionary*errors = [ NSDictionary dictionary ];
	NSAppleScript 	*script = [[ NSAppleScript alloc ]  
initWithContentsOfURL:url error:&errors ];


I check the URL to make sure that it is valid.
Now if I dont use Guard Malloc the scripts load properly and I dont  
get any errors either.

So any ideas? Could I just by pass this in my exception handling?

Also is it a bad idea to leave MallocStackLogging,  
MallocStackLoggingNoCompact, MallocScribble in the release version.


Thanks
Reza

Does this make any sense to you. From that point the app goes into


On 3 Mar 2009, at 06:38, Paul Sanders wrote:

(Reza sent me the message below privately but I thought it might be  
useful
to copy the reply to the list.  Excuse me if you have heard it all  
before).



So you would think this is happening in the Exception Handling code?


No, I don't think it's happening on the exception handler.   I think  
that is
trapping it, rather than causing it.  To help track the problem  
down, take a

look at this:

http://developer.apple.com/technotes/tn2004/tn2124.html

As a starting point, try running your program under GDB with Guard  
Malloc
enabled.  This often traps memory allocation errors at source,  
although it

can slow things down a lot.  If that is too slow, try setting
MallocScribble, MallocPreScribble, MallocGuardEdges and  
MallocStackLogging

in your environment as described in the article.  You can set these
variables in XCode via Get Info - Arguements on your executable.   
Check out
also NSZombieEnabled, see http://www.cocoadev.com/index.pl?NSZombieEnabled 
.
When this is set in the environment, the runtime will trap any  
reference to

a freed object.

Hope this helps and thanks very much for sending me your code  - Paul.



___

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: Odd crash

[Paul Sanders]

> Given that it's between the (presumably) crashing code and _sigtramp,
> my bet is that it's some sort of signal handler goop.

Oh!  I just took a copy of that code :).  I'll look at it when I get a 
moment. 

___

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: Odd crash

[Andrew Farmer]

On 02 Mar 09, at 20:22, Kyle Sluder wrote:
On Mon, Mar 2, 2009 at 7:02 PM, Paul Sanders  
 wrote:

As the man said, over-releaseing something, perhaps.


0x is on the call stack... maybe it's defensive scribbling,
not an overrelease.


Given that it's between the (presumably) crashing code and _sigtramp,  
my bet is that it's some sort of signal handler goop.

___

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: Odd crash

[Paul Sanders]

(Reza sent me the message below privately but I thought it might be useful 
to copy the reply to the list.  Excuse me if you have heard it all before).

> So you would think this is happening in the Exception Handling code?

No, I don't think it's happening on the exception handler.   I think that is 
trapping it, rather than causing it.  To help track the problem down, take a 
look at this:

http://developer.apple.com/technotes/tn2004/tn2124.html

As a starting point, try running your program under GDB with Guard Malloc 
enabled.  This often traps memory allocation errors at source, although it 
can slow things down a lot.  If that is too slow, try setting 
MallocScribble, MallocPreScribble, MallocGuardEdges and MallocStackLogging 
in your environment as described in the article.  You can set these 
variables in XCode via Get Info - Arguements on your executable.  Check out 
also NSZombieEnabled, see http://www.cocoadev.com/index.pl?NSZombieEnabled. 
When this is set in the environment, the runtime will trap any reference to 
a freed object.

Hope this helps and thanks very much for sending me your code  - Paul. 

___

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: Odd crash

[Kyle Sluder]

On Mon, Mar 2, 2009 at 7:02 PM, Paul Sanders  wrote:
> As the man said, over-releaseing something, perhaps.

0x is on the call stack... maybe it's defensive scribbling,
not an overrelease.

--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: Odd crash

[Paul Sanders]

> I am getting an odd crash report from some of my end users at startup.
> The report attached below is generated by using a custom uncaught
> exceptions handlers. I can not make any sense of this as all the calls
> are within the Apple frameworks. Ay suggestions.
> Thanks

As the man said, over-releaseing something, perhaps.

Can I scrounge* a copy of you custom exception handler please?  If it's 
convenient, perhaps you cluld email me a copy.  I won't mind if you say no.

---

*Scrounge: beg, steal, borrow, or all three :) 

___

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: Odd crash

[Michael Ash]

On Mon, Mar 2, 2009 at 3:52 PM, Reza Farhad  wrote:
> I am getting an odd crash report from some of my end users at startup. The
> report attached below is generated by using a custom uncaught exceptions
> handlers. I can not make any sense of this as all the calls are within the
> Apple frameworks. Ay suggestions.
> Thanks
>
> Reza
>
> System: Mac OS X 10.5.6 (Build 9G55)
>
> NSUncaughtSystemExceptionException
>
> Uncaught system exception: signal 10
>
> NSExceptionHandlerUncaughtSignalHandler (in ExceptionHandling) + 65
> _sigtramp (in libSystem.B.dylib) + 43
> 0x
> -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] (in
> Foundation) + 87
> _NSURLConnectionDidFinishLoading (in Foundation) + 147
> URLConnectionClient::clientDidFinishLoading() (in CFNetwork) + 174
> URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo XClientEventParams>*, long) (in CFNetwork) + 281
> URLConnectionClient::processEvents() (in CFNetwork) + 114
> MultiplexerSource::perform() (in CFNetwork) + 189
> CFRunLoopRunSpecific (in CoreFoundation) + 3141
> CFRunLoopRunInMode (in CoreFoundation) + 88
> RunCurrentEventLoopInMode (in HIToolbox) + 283
> ReceiveNextEventCommon (in HIToolbox) + 374
> BlockUntilNextEventMatchingListInMode (in HIToolbox) + 106
> _DPSNextEvent (in AppKit) + 657
> -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit)
> + 128
> -[NSApplication run] (in AppKit) + 795
> NSApplicationMain (in AppKit) + 574
> start (in Qu-s) + 54
> 0x2

I'm clueless as to why this would show up as an NSException, but
signal 10 is SIGBUS, a.k.a. bus error, which is a common symptom of
memory management problems. Turn on zombies (or tell the user to) and
see if a more informative error is given.

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

Odd crash

[Reza Farhad]

I am getting an odd crash report from some of my end users at startup.  
The report attached below is generated by using a custom uncaught  
exceptions handlers. I can not make any sense of this as all the calls  
are within the Apple frameworks. Ay suggestions.

Thanks

Reza

System: Mac OS X 10.5.6 (Build 9G55)

NSUncaughtSystemExceptionException

Uncaught system exception: signal 10

NSExceptionHandlerUncaughtSignalHandler (in ExceptionHandling) + 65
_sigtramp (in libSystem.B.dylib) + 43
0x
-[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading]  
(in Foundation) + 87

_NSURLConnectionDidFinishLoading (in Foundation) + 147
URLConnectionClient::clientDidFinishLoading() (in CFNetwork) + 174
URLConnectionClient 
::ClientConnectionEventQueue 
::processAllEventsAndConsumePayload(XConnectionEventInfoXClientEventParams>*, long) (in CFNetwork) + 281

URLConnectionClient::processEvents() (in CFNetwork) + 114
MultiplexerSource::perform() (in CFNetwork) + 189
CFRunLoopRunSpecific (in CoreFoundation) + 3141
CFRunLoopRunInMode (in CoreFoundation) + 88
RunCurrentEventLoopInMode (in HIToolbox) + 283
ReceiveNextEventCommon (in HIToolbox) + 374
BlockUntilNextEventMatchingListInMode (in HIToolbox) + 106
_DPSNextEvent (in AppKit) + 657
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in  
AppKit) + 128

-[NSApplication run] (in AppKit) + 795
NSApplicationMain (in AppKit) + 574
start (in Qu-s) + 54
0x2
___

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