I do not have a solution but hopefully i can point you to right direction:
It crashes when the window is trying to become key window. "becomeKeyWindow
" [NSWindow becomeKeyWindow].
It crashes in _dataSourceValueForColumn:row:
It crashes on selector objectAtIndex:

According to dissasembly column is retrieved and send as a parameter to
crashing function.
For me it looks like there is something wrong with the number of
tableColumns.


Here is Hopper disassembly of [NSTableView preparedCellAtColumn:row:]

loc_28c782:

    LODWORD(r13) = 0x0;

    if (rbx >= 0x0) {

            r13 = [r12->_tableColumns objectAtIndex:rbx];

    }

    var_38 = [r12 _dataSourceValueForColumn:r13 row:r14];

    if (r15 == 0x0) {

            r15 = [r12 _dataCellForTableColumn:r13 row:r14];

    }

Here is Hopper disassembly of [NSTableView _dataSourceValueForColumn:row:]


void * -[NSTableView _dataSourceValueForColumn:row:](void * self, void *
_cmd, void * arg2, long long arg3) {

    rax = arg3;

    r14 = arg2;

    rbx = self;

    if ((*(int8_t *)(rbx->_reserved +
*_OBJC_IVAR_$__NSTableViewReserved._tvFlags2 + 0x1) & 0x8) != 0x0) {

            rdi = rbx->_dataSource;

            rdx = rbx;

            rcx = r14;

            rax = [rdi tableView:rdx objectValueForTableColumn:rcx row:rax];

    }

    else {

            if (([rbx _bindingAdaptor] == 0x0) && (r14 != 0x0)) {

                    if (([r14 _bindingAdaptor] == 0x0) && (rbx->_rowDataX
== 0x0)) {

                            [rbx _printDatasourceWarning];

                    }

            }

            LODWORD(rax) = 0x0;

            return rax;

    }

    return rax;

}





On Sat, Mar 14, 2015 at 9:14 AM, Peter Hudson <peter.hud...@me.com> wrote:

> I don't get to the situation where I would need to set the delegate to
> zero - the user isn't closing the app down when the crashes occur. The
> whole relationship of delegate and datasource is setup when a project is
> opened - and remains the same throughout. ‎It simply hoses along the way.
> Peter
>
>   Original Message
> From: Lee Ann Rucker
> Sent: Friday, 13 March 2015 19:57
> To: Peter Hudson
> Cc: Steve Mills; ms_li...@shiftoption.com; Cocoa dev
> Subject: Re: Weird crashes on Yosemite
>
> Your code may not have changed, but Apple's code has - are you still using
> reference counting? Because I'm willing to bet that NSTableView isn't, and
> I filed rdar://17733863 over a situation very much like this one - the
> workaround was to setDelegate:nil earlier than you might think necessary.
>
> On Mar 13, 2015, at 8:11 AM, Peter Hudson <peter.hud...@me.com> wrote:
>
> > Thanks for these suggestion Steve and Markus.
> >
> > The table datasource and delegate code has been running very sweetly for
> a number of years and has not been changed since it was written some time
> back.
> > The table datasource in this case is completely central to the program -
> and I never change the datasource or delegate for this table.
> >
> > That said, the suggestions are interesting - I will try out the
> debugging ideas.
> > My problem is, I can’t reproduce a crash to order !
> > This one happened after the user had been working for three hours.
> >
> > Peter
> >
> >
> >
> >
> >> On 13 Mar 2015, at 14:55, Steve Mills <sjmi...@mac.com> wrote:
> >>
> >> On Mar 13, 2015, at 09:46:36, Peter Hudson <peter.hud...@me.com> wrote:
> >>
> >>> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
> >>>
> >>> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> >>> Exception Codes: KERN_INVALID_ADDRESS at 0x00000000ffffffff
> >>>
> >>> objc_msgSend() selector name: objectAtIndex:
> >>>
> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> >>> 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27
> >>> 1 com.apple.AppKit 0x9184a305 -[NSTableView
> _dataSourceValueForColumn:row:] + 69
> >>> 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:]
> + 385
> >>> 3 com.apple.AppKit 0x917efc91 -[NSTableView
> _dirtyVisibleCellsForKeyStateChange] + 878
> >>
> >> What do you have set as the dataSource for the table? Is it still valid
> when the window owning the table becomes key? Is it owned by some object
> that might be in a weak property instead of strong? (Although you would
> probably see that right away when you debugged it.) Have you run static
> analysis on the project? Have you turned on Scribble, Guard Edges, and
> Guard Malloc in your scheme while debugging? Some of those can sometimes
> help force bugs to the surface.
> >>
> >> --
> >> Steve Mills
> >> Drummer, Mac geek
> >>
> >
> >
> >
> >
> > On 13/03/15 15:46, Peter Hudson wrote:
> >> Any comments or suggestions gratefully received !
> >>
> >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> >> 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27
> >> 1 com.apple.AppKit 0x9184a305 -[NSTableView
> _dataSourceValueForColumn:row:] + 69
> >> 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:]
> + 385
> >> 3 com.apple.AppKit 0x917efc91 -[NSTableView
> _dirtyVisibleCellsForKeyStateChange] + 878
> >> 4 com.apple.AppKit 0x917ef6de -[NSTableView _windowChangedKeyState] +
> 323
> >
> > This looks like a table's delegate or datasource has been disposed off
> while the table still uses it. Make sure to set table delegates/datasources
> to nil when the object being used as delegate/datasource is deallocated.
> >
> > Regards
> > Markus
> > --
> > _______________________________________________
> >
> > 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/lrucker%40vmware.com
> >
> > This email sent to lruc...@vmware.com
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/xhruso00%40gmail.com
>
> This email sent to xhrus...@gmail.com
>
_______________________________________________

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

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

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

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

Reply via email to