Runtime exception

[miklselsoe]

I've just installed Greenwich in my (rather large) project. When I run my (Mac) app, I get a bunch of exceptions like the one below - one for each of my NSTableColumns it seems. It seems that Greenwich doesn't like when a NSTableColumn has its identifier set in IB. As you can see, I don't have the symbolicated stack frames from Greenwich. Maybe you can symbolicate - otherwise I can probably build the framework myself and find the callers if needed.

2012-06-29 14:54:14.997 MyApp [46499:b03] Object POTableColumn: 0x16385e2e0 identifier: ID_Picture is not usable with binder of class NSTextValueBinder
2012-06-29 14:54:15.001 MyApp [46499:b03] (
    0   CoreFoundation                      0x00007fff8d9c6f56 __exceptionPreprocess + 198
    1   libobjc.A.dylib                     0x00007fff8db3ed5e objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff8da511b9 -[NSException raise] + 9
    3   ExceptionHandling                   0x0000000103711c90 NSExceptionHandlerExceptionRaiser + 208
    4   libobjc.A.dylib                     0x00007fff8db3ed5e objc_exception_throw + 43
    5   CoreFoundation                      0x00007fff8d9c6d8a +[NSException raise:format:arguments:] + 106
    6   CoreFoundation                      0x00007fff8d9c6d14 +[NSException raise:format:] + 116
    7   AppKit                              0x00007fff8aae3f47 -[NSBinder initWithObject:] + 173
    8   AppKit                              0x00007fff8ace96f7 +[NSValueBinder bindingsForObject:] + 53
    9   AppKit                              0x00007fff8abc62b3 -[NSBinder availableBindings] + 66
    10  AppKit                              0x00007fff8ace9df5 -[NSValueBinder availableBindings] + 47
    11  AppKit                              0x00007fff8aadb71a -[NSObject(NSKeyValueBindingCreation) _binderForBinding:withBinders:createAutoreleasedInstanceIfNotFound:] + 167
    12  AppKit                              0x00007fff8af1c623 -[NSObject(NSKeyValueBindingCreation) infoForBinding:] + 45
    13  Greenwich                           0x00000001039dcf09 Greenwich + 28425
    14  Greenwich                           0x00000001039dc502 Greenwich + 25858
    15  Greenwich                           0x00000001039dc624 Greenwich + 26148
    16  Greenwich                           0x00000001039dc502 Greenwich + 25858
    17  Greenwich                           0x00000001039dc5c5 Greenwich + 26053
    18  Greenwich                           0x00000001039dc502 Greenwich + 25858
    19  Greenwich                           0x00000001039dc5c5 Greenwich + 26053
    20  Greenwich                           0x00000001039dc502 Greenwich + 25858
    21  Greenwich                           0x00000001039dc5c5 Greenwich + 26053
    22  Greenwich                           0x00000001039dd209 Greenwich + 29193
    23  Greenwich                           0x00000001039dc502 Greenwich + 25858
    24  Greenwich                           0x00000001039dc624 Greenwich + 26148
    25  Greenwich                           0x00000001039dc502 Greenwich + 25858
    26  Greenwich                           0x00000001039dc5c5 Greenwich + 26053
    27  Greenwich                           0x00000001039dc502 Greenwich + 25858
    28  Greenwich                           0x00000001039dc273 Greenwich + 25203
    29  Greenwich                           0x00000001039dbf70 Greenwich + 24432
    30  AppKit                              0x00007fff8acb6c34 -[NSWindowController loadWindow] + 221

[wbyoung]

It looks like it's more likely related to bindings… I can't reproduce with just an identifier. I'll come back and symbolicate this later, but really quickly: what bindings do you have set up on your table columns?

[miklselsoe]

You are right. In both cases (I have two tableviews with columns that have this problem) their values are bound in IB to a NSArrayController.

[wbyoung]

In general, bindings should work. What exactly are they bound to? Do they use transformers? Any detail that you can give about how they're set up will help. What would be really great is if you could reproduce the crash in a small example App. :)

[wbyoung]

Just wanted to check to see if you saw my last message — I haven't been able to reproduce this problem, but I would very much like to get it fixed for you!

[miklselsoe]

Hi

I'm sorry I didn't get back to you. Things have been a bit busy. I will look into this again as soon as I can. I really hope I can get Greenwich up and running soon. :) Were you able to symbolicate the stack trace? Otherwise I will try with a local build of Greenwich to get a bit more information.

[wbyoung]

I didn't symbolicate it yet because I'm pretty sure I know where it's originating from in the Greenwich source code. I do have the dSYM files, so I should be able to if need be. Really, I just want to be able to reproduce it because that will allow me to fix it fastest. If you're willing to send over the xib file, I could even take a look at that as a starting place, but I know that's a little sensitive. If you're willing, you can email it to me directly. My email is my GitHub handle at fadingred.com.

[miklselsoe]

OK, here's what I found out (unfortunately I cannot share the files with you):
In IB a binding is set up from NSTableViewColumn to a value that is actually a NSColor object. In IB, the cell of the column is a NSTextFieldCell. In awakeFromNib in File's Owner, the cell is replaced with a custom (NSCell class) cell using the setDataCell: call on NSTableColumn. It seems that when Greenwich calls infoForBinding: it doesn't know that the cell has been swapped and a crash occurs because a NSTextFieldCell obviousely doesn't know what to do with a NSColor object. If I replace the cell in IB to be a NSCell, it gets past the exception. Of course it would be nice if Greenwich handled this situation better though.

After this I get another crash that might or might not be related (same situation in a different NSTableViewColumn perhaps). I haven't found the source of that yet. I can post more on that if I find out more.

Unrelated: Is there some documentation on how Greenwich acutally works behind the scenes? That these situations occur worry me a little and makes me wonder what kind of runtime overhead the framework may actually impose? I was hoping/expecting that it would be less intrusive. Maybe I just misunderstood how it's supposed to work.