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,
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'in
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 probl
: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
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
an
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:
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
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 submit
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,
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
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:
>>>
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];
>> [_colo
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, w
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, i
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 wi
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 (n
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 actio
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 w
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 t
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 usu
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 af
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 righ
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
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
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 messa
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 wi
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
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:]
> #3
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.ExceptionHa
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 w
ver 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
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
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 commen
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 so
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 -ad
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 subvie
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 everyt
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::GetSyncGC
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
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
jniak"
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 lis
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 wh
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
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 guess
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 l
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 a
> 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:
>>>
>>
> 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,
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 a
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*
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
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 m
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 M
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 neve
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
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 di
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 Ma
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 ]
init
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
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 er
> 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
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
(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
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@list
> 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
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 th
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
67 matches
Mail list logo
