Re: Crashes while reordering columns in a NSTableView
On 22/07/2009, at 2:42 AM, Nick Zitzmann wrote:
One thought: Are you using the -CGImage method of NSBitmapImageRep
anywhere? If so, then you absolutely must not deallocate the
NSBitmapImageRep while the CGImageRef is live, because the
CGImageRef acquired via -CGImage is still using the
NSBitmapImageRep's data.
Hm, that's interesting. I'm using Garbage Collection, so does this
mean that I can't do this and get away with it?:
@implementation NSImage (Additions)
- (CGImageRef)CGImage;
{
return [[[NSBitmapImageRep alloc] initWithData:[self
TIFFRepresentation]] CGImage];
}
@end
Could explain a few things...
--
Rob Keniger
___
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: Crashes while reordering columns in a NSTableView
Am 21.07.2009 um 00:38 schrieb Tim Schmidt: Is there any way to work around this Yes: find your memory bug. EXC_BAD_ACCESS almost always is a memory bug in your code. atze ___ 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: Crashes while reordering columns in a NSTableView
On Jul 20, 2009, at 11:18 PM, Alexander Spohr wrote: Am 21.07.2009 um 00:38 schrieb Tim Schmidt: Is there any way to work around this Yes: find your memory bug. EXC_BAD_ACCESS almost always is a memory bug in your code. atze Obviously CG's bitblock transfers access unallocated memory in this case. If I accidently free said memory it completely eludes me where this might happen (I am pretty confident I don't release any of my model/controller objects unintentionally (I tried running with all the usual mallocdebug options as well as NSZombies). Furthermore all NIBs are managed by NSViewController subclasses. Can anybody point me to some advanced guides on NSTableView (beyond the class reference and tables guide). ___ 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: Crashes while reordering columns in a NSTableView
On Tue, Jul 21, 2009 at 9:32 AM, Tim Schmidtschmidt@gmx.net wrote: Obviously CG's bitblock transfers access unallocated memory in this case. No, it probably doesn't. Remember, 90% of the time, the bug is in your code. The other 10% of the time, the bug is in your code. If I accidently free said memory it completely eludes me where this might happen (I am pretty confident I don't release any of my model/controller objects unintentionally (I tried running with all the usual mallocdebug options as well as NSZombies). Use Instruments. Furthermore all NIBs are managed by NSViewController subclasses. Can anybody point me to some advanced guides on NSTableView (beyond the class reference and tables guide). There aren't any. It's not a hard class to work with. --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: Crashes while reordering columns in a NSTableView
On Jul 21, 2009, at 12:32 PM, Tim Schmidt wrote: Obviously CG's bitblock transfers access unallocated memory in this case. If I accidently free said memory it completely eludes me where this might happen (I am pretty confident I don't release any of my model/controller objects unintentionally (I tried running with all the usual mallocdebug options as well as NSZombies). Furthermore all NIBs are managed by NSViewController subclasses. Can anybody point me to some advanced guides on NSTableView (beyond the class reference and tables guide). I'll assume you're not customizing the drag and drop process (or doing anything with the column drag delegate method). My own intuition tells me you might look into your cells. If you have any custom (header or data) cells for the column(s) involved or do any custom manipulation of those cells (such as with ...willDisplayCell:...) that'd be a place to start looking for memory management no-nos. Especially if it only happens with particular columns. Also, if you're using the table datasource protocol, it's possible your ...objectValue... datasource method is returning an improperly- managed instance of something or other. If you're doing anything custom, post your code. -- I.S. ___ 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: Crashes while reordering columns in a NSTableView
On Jul 21, 2009, at 10:32 AM, Tim Schmidt wrote: Obviously CG's bitblock transfers access unallocated memory in this case. If I accidently free said memory it completely eludes me where this might happen (I am pretty confident I don't release any of my model/controller objects unintentionally (I tried running with all the usual mallocdebug options as well as NSZombies). Furthermore all NIBs are managed by NSViewController subclasses. Can anybody point me to some advanced guides on NSTableView (beyond the class reference and tables guide). One thought: Are you using the -CGImage method of NSBitmapImageRep anywhere? If so, then you absolutely must not deallocate the NSBitmapImageRep while the CGImageRef is live, because the CGImageRef acquired via -CGImage is still using the NSBitmapImageRep's data. Nick Zitzmann http://www.chronosnet.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: Crashes while reordering columns in a NSTableView
On Tuesday, July 21, 2009, Kyle Sluder kyle.slu...@gmail.com wrote: Remember, 90% of the time, the bug is in your code. The other 10% of the time, the bug is in your code. That's just not true. Plenty of bugs in the frameworks. I've personally logged dozens. It's USUALLY your code but certainly not always. There aren't any. It's not a hard class to work with. Except when it is. Why so many absolutes? Try customizing table views / columns / header views / etc. I mean beyond setting a custom data cell or adding keyboard actions. Some of these mechanisms work in unexpected (and sometimes conflicting) ways. Not all of This behavior is documented either. It's not insurmountable but it's far from easy. Tables are fairly complicated UI. If you have an app where a column is a first-class conceptual model, for example, you might need a more interactive header cell ... There be dragons. As to the OP's problem, however, I suspect the real issue is probably pretty simple since he did not mention heavy customization. Could be wrong though ... -- I.S. ___ 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: Crashes while reordering columns in a NSTableView
On Tue, Jul 21, 2009 at 9:56 AM, I. Savantidiotsavant2...@gmail.com wrote: That's just not true. Plenty of bugs in the frameworks. I've personally logged dozens. It's USUALLY your code but certainly not always. It's not intended to be an accurate statement. The point is to avoid jumping to conclusions. Framework code is far more exposed than your own, and it is immensely more likely that you've screwed up than the Quartz devs have. If you have an app where a column is a first-class conceptual model, for example, you might need a more interactive header cell ... There be dragons. You mean like OmniOutliner? :) As to the OP's problem, however, I suspect the real issue is probably pretty simple since he did not mention heavy customization. Could be wrong though ... This is where I was coming from. Then I looked at the stack trace and saw NSLayerKitGlue. He might not be doing anything complicated, but AppKit is. --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: Crashes while reordering columns in a NSTableView
It's not intended to be an accurate statement. The point is to avoid jumping to conclusions. Framework code is far more exposed than your own, and it is immensely more likely that you've screwed up than the Quartz devs have. I get that. I just don't think that's necessarily a good place to make that assertion. :-) My younger self spent hours on a bug I was sure was mine because it couldn't possibly be the API ... it was the API. :-) If you have an app where a column is a first-class conceptual model, for example, you might need a more interactive header cell ... There be dragons. You mean like OmniOutliner? :) I realize you work at Omni Group, so you see my point. :-) It's far from trivial to get this stuff heavily customized until you've spent a long time doing just that. Still - I own a copy of OmniOutliner registered to my real name - I see that the column headers (beyond a different drawing style) really only add right-click-to-show-context-menu action. That simple approach works perfectly for OmniOutliner, but I can think of more complicated scenarios where more direct interaction with the header itself would be the most natural approach ... *There* be dragons. :-D This is where I was coming from. Then I looked at the stack trace and saw NSLayerKitGlue. He might not be doing anything complicated, but AppKit is. All I was saying there was that it's not really possible to assign a difficulty level as we don't really know what the OP is trying yet. :-) A note: Positively no disrespect intended. -- I.S. ___ 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
Crashes while reordering columns in a NSTableView
Hi all, I am having a lot of problems with NSTableView crashing my application, when reordering (dragging) columns. The crashes either take down the whole app and all I get is the following message: Error: __CGPixelAccessDataInitialize: vm_copy failed: status 1. or, it manages to break into the debugger with stack-traces like the following (nearly all crashes happen in CGBlt_copyBytes with an EXC_BAD_ACCESS signal. Thread 1: #0 0x90ec0fb9 in CGBlt_copyBytes () #1 0x90ef7e70 in __CGPixelAccessDataInitialize () #2 0x9144b010 in __CGPixelAccessAccessBitmapData () #3 0x90f2eab8 in __CGPixelAccessCreateImageFromRect () #4 0x90f2e916 in CGPixelAccessCreateImageFromRect () #5 0x90720ec5 in -[NSCGImageRep initWithFocusedViewRect:] () #6 0x906544cc in -[NSTableView _captureReorderResizeColumnImageCaches] () #7 0x90653261 in -[NSTableView drawRect:] () #8 0x9072c75a in -[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inContext:topView:] () #9 0x90cc7f08 in -[NSView(NSLayerKitGlue) drawLayer:inContext:] () #10 0x96c7bf00 in -[CALayer drawInContext:] () #11 0x96e7036c in tiled_layer_render () #12 0x96e2a267 in source_perform () #13 0x9737b595 in CFRunLoopRunSpecific () #14 0x9737bc78 in CFRunLoopRunInMode () #15 0x939b928c in RunCurrentEventLoopInMode () #16 0x939b8fde in ReceiveNextEventCommon () #17 0x939b8f19 in BlockUntilNextEventMatchingListInMode () #18 0x9061ad0d in _DPSNextEvent () #19 0x9061a5c0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #20 0x90b91d59 in -[NSTableHeaderView _lastDraggedOrUpEventFollowing:canceled:] () #21 0x90b92426 in -[NSTableHeaderView _reorderColumn:withEvent:] () #22 0x908d6c63 in -[NSTableHeaderView mouseDown:] () #23 0x906e9133 in -[NSWindow sendEvent:] () #24 0x906b5cd9 in -[NSApplication sendEvent:] () #25 0x9061362f in -[NSApplication run] () #26 0x905e0834 in NSApplicationMain () #27 0x2af2 in main (argc=1, argv=0xb640) at X/main.m: 13 Thread 2: #0 0x9368446e in __semwait_signal () #1 0x936af3e6 in _pthread_cond_wait () #2 0x936aedcd in pthread_cond_wait$UNIX2003 () #3 0x931d9329 in CVDisplayLink::runIOThread () #4 0x936ae155 in _pthread_start () #5 0x936ae012 in thread_start () Thread 3: #0 0x9368446e in __semwait_signal () #1 0x936af3e6 in _pthread_cond_wait () #2 0x936aedcd in pthread_cond_wait$UNIX2003 () #3 0x964beb32 in glvmDoWork () #4 0x936ae155 in _pthread_start () #5 0x936ae012 in thread_start () Reordering columns also leads to strange artifacts (it works for a few seconds before it crashes...). Said table is programmatically manipulated at runtime (i.e. columns are removed | added). The superview uses CG. Xcode also occasionally dumps the following to console if gdb manages to break: Xcode could not locate source file: cpu_capabilities.h (line: 246) Is there any way to work around this, as Column reordering is a pretty important feature for this tool Very best regards, Tim Schmidt ___ 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
