Re: Not Receiving Distributed Notifications Unless in Focus
We're seeing problems similar to this too, and have a Radar in to Apple about it. Ken's comment about the change to suspension behavior in Lion is an important one, but the problem still exists even after taking that into account. Our situation is a bit more complicated, so perhaps there are other factors involved and all you need to do is mess with the suspension settings, but you're not the only one having trouble with this. Sorry I don't have a solution yet to share, though; if you also find changing the suspension behavior just results in different problems that you solve, I'd be interested in hearing your solution. Best, br___ 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
Lion autosave: Undefined st_flags 0x40 bit being set, causing errors
Our application copies files in response to filesystem events, and in some cases that seem correlated with Lion’s autosave system (e.g. in TextEdit and Pages), the undefined 0x40 bit is being set in the files’ st_flags fields. When trying to set these flags on the destination copy over AFP, we get EINVAL. Since this flag is nominally undefined (though clearly actually in use in some way), it’s not clear how we should handle this situation for maximum safety and compatibility. Could any Apple folk chime in on what this flag is doing and what we should do about it? Or has anybody managed to reverse engineer any meaning out of it? Thanks, Benjamin Rister___ 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: Lion document opening: -[__NSArrayM insertObject:atIndex:]: object cannot be nil
On Aug 5, 2011, at 10:19 AM, Sean McBride wrote: I bet its related to Resume, try turning it off from Sys Prefs or passing -ApplePersistenceIgnoreState YES as an argument at launch. That’s an interesting idea, but unfortunately the agent is already running (and has been for a while) when the document is opened, so Resume’s time has come and gone and it shouldn’t be involved in anything happening at that point in time. Best, br___ 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
Lion document opening: -[__NSArrayM insertObject:atIndex:]: object cannot be nil
We have an agent (UIElement) process, using GC, that can open a custom document type. Other than it being an agent, there’s nothing particularly special going on. On Lion, when one of these documents are opened, the window appears, but then the application promptly has an uncaught exception and crashes. The difficult matter here is that there’s no code of ours in the stack trace involving the exception, it just looks like internal NSDocumentController machinery, and everything works fine on 10.6. So while as a first pass this looks like it could be a Lion bug, I thought I’d run it past the hive mind here to see if anybody has seen any issues like it themselves and have any insight into a workaround or anything that we could be doing wrong to be causing it. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil' *** First throw call stack: ( 0 CoreFoundation 0x7fff8882f986 __exceptionPreprocess + 198 1 libobjc.A.dylib0x7fff8a38ad5e objc_exception_throw + 43 2 CoreFoundation 0x7fff887d6818 -[__NSArrayM insertObject:atIndex:] + 296 3 AppKit 0x7fff8d47d242 __-[NSApplication(NSAppleEventHandling) _handleAEOpenDocumentsForURLs:]_block_invoke_2 + 1089 4 AppKit 0x7fff8d581b85 __-[NSDocumentController _openDocumentsWithContentsOfURLs:presentErrors:completionHandler:]_block_invoke_2 + 50 5 Foundation 0x7fff88add581 -[NSBlockOperation main] + 116 6 Foundation 0x7fff88aa40b0 -[__NSOperationInternal start] + 705 7 Foundation 0x7fff88ab73d2 NSOQSchedule_block_invoke_2 + 124 8 libdispatch.dylib 0x7fff8ca6d90a _dispatch_call_block_and_release + 18 9 libdispatch.dylib 0x7fff8ca6f77a _dispatch_main_queue_callback_4CF + 308 10 CoreFoundation 0x7fff887c4c0c __CFRunLoopRun + 1724 11 CoreFoundation 0x7fff887c4216 CFRunLoopRunSpecific + 230 12 HIToolbox 0x7fff92b0a4ff RunCurrentEventLoopInMode + 277 13 HIToolbox 0x7fff92b11c21 ReceiveNextEventCommon + 355 14 HIToolbox 0x7fff92b11aae BlockUntilNextEventMatchingListInMode + 62 15 AppKit 0x7fff8d1c1191 _DPSNextEvent + 659 16 AppKit 0x7fff8d1c0a95 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 17 AppKit 0x7fff8d1bd3d6 -[NSApplication run] + 463 18 AppKit 0x7fff8d43b52a NSApplicationMain + 867 19 Synk Agent 0x000120ec Synk Agent + 8428 20 ???0x0001 0x0 + 1 ) Any insight or info would be appreciated. Best, Benjamin Rister___ 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 in _Unwind_Resume
Greg Parker wrote: You might try installing an @try/@catch block in main. If the unwinder is working long enough to get there then you can log something to help debug further. You can use `...@catch (NSException *e)` to check for Objective-C exceptions and `...@catch (...)` to check for C++ exceptions. Excellent, thanks for all the info and the suggestion. I’ll do this and see if anything drops out of it. vincent habchi wrote: By the way, both thread 0 and 2 seem to be in the same routine by the time it crashes. Are you sure all your variables are thread safe? That function is CFRunLoopRun, which is explicitly meant for use on different threads. (Yes, they’re separate run loops.) Joar Wingfors wrote: The default system compiler on Mac OS X is GCC, not LLVM. True enough, but Xcode and other non-trivial apps are compiled with LLVM, and for quite some time the message out of Apple’s devtools team has been to migrate to LLVM. I even seem to recall hearing at WWDC that the only reason they didn’t change the default compiler in some recent version of Xcode was because it just seemed wrong to do that in a maintenance release. I still can’t use pure LLVM due to Clang bugs, but GCC LLVM (which is what devtools advocates) appears to be working well. Roland King wrote: Adding a try/catch around some main bits of the app found the real issue for me. Another good suggestion, thanks. This may be a bit hard for me, because this app has a lot of dispatching to the main thread, but between Greg’s suggestion and yours, perhaps I can get a critical clue logged. Thanks, everyone. I’ll give it all a shot and we’ll see how it goes. Benjamin Rister___ 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 in _Unwind_Resume
We’ve started seeing sporadic but regular crashes from _Unwind_Resume in a Foundation tool. The crashing thread is: Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x7fff87e363d6 __kill + 10 1 libSystem.B.dylib 0x7fff87ed6972 abort + 83 2 libSystem.B.dylib 0x7fff87e56972 _Unwind_Resume + 66 3 com.apple.CoreFoundation 0x7fff86e43a91 CFRunLoopRunSpecific + 1153 4 com.apple.CoreFoundation 0x7fff86e435d6 CFRunLoopRun + 70 5 net.decimus.Synk.Engine 0x000114bb main + 615 6 net.decimus.Synk.Engine 0x0001124c start + 52 The other threads aren’t doing anything noteworthy and are just sitting idle, but I’ll include the whole crash log below for completeness. It’s obviously involved with exception handling, perhaps an uncaught exception, except that we’re not getting any of the usual information in the crash log that we typically do with an Obj-C exception. From my web searches, I suspect something C++ is the culprit, but because we have zero C++ code of our own in this binary, I have no idea where the problem could be or how to do anything about it. Any suggestions on how to track this down and fix it, or work around it if it’s a system bug? Or has anybody seen this before and already know what the issue is? Thanks, Benjamin Rister Full crash log: Process: Synk Engine [676] Path:/Library/Synk/bin/Synk Engine.app/Contents/MacOS/Synk Engine Identifier: Synk Engine Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [1] Date/Time: 2010-08-24 10:24:15.095 +0800 OS Version: Mac OS X 10.6.4 (10F569) Report Version: 6 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called objc[676]: garbage collection is ON Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x7fff87e363d6 __kill + 10 1 libSystem.B.dylib 0x7fff87ed6972 abort + 83 2 libSystem.B.dylib 0x7fff87e56972 _Unwind_Resume + 66 3 com.apple.CoreFoundation0x7fff86e43a91 CFRunLoopRunSpecific + 1153 4 com.apple.CoreFoundation0x7fff86e435d6 CFRunLoopRun + 70 5 net.decimus.Synk.Engine 0x000114bb main + 615 6 net.decimus.Synk.Engine 0x0001124c start + 52 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x7fff87e0108a kevent + 10 1 libSystem.B.dylib 0x7fff87e02f5d _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x7fff87e02c34 _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x7fff87e0275e _dispatch_worker_thread2 + 252 4 libSystem.B.dylib 0x7fff87e02088 _pthread_wqthread + 353 5 libSystem.B.dylib 0x7fff87e01f25 start_wqthread + 13 Thread 2: 0 libSystem.B.dylib 0x7fff87de82fa mach_msg_trap + 10 1 libSystem.B.dylib 0x7fff87de896d mach_msg + 59 2 com.apple.CoreFoundation0x7fff86e443c2 __CFRunLoopRun + 1698 3 com.apple.CoreFoundation0x7fff86e4384f CFRunLoopRunSpecific + 575 4 com.apple.Foundation0x7fff85073a18 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 270 5 net.decimus.Synk.Engine 0x000100021c41 -[EngineServer main] + 111 6 com.apple.Foundation0x7fff85038e8d __NSThread__main__ + 1429 7 libSystem.B.dylib 0x7fff87e21456 _pthread_start + 331 8 libSystem.B.dylib 0x7fff87e21309 thread_start + 13 Thread 3: 0 libSystem.B.dylib 0x7fff87e2bdce select$DARWIN_EXTSN + 10 1 com.apple.CoreFoundation0x7fff86e65e92 __CFSocketManager + 818 2 libSystem.B.dylib 0x7fff87e21456 _pthread_start + 331 3 libSystem.B.dylib 0x7fff87e21309 thread_start + 13 Thread 4: 0 libSystem.B.dylib 0x7fff87e01eaa __workq_kernreturn + 10 1 libSystem.B.dylib 0x7fff87e022bc _pthread_wqthread + 917 2 libSystem.B.dylib 0x7fff87e01f25 start_wqthread + 13 Thread 5: Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x000100225c50 rcx: 0x7fff5fbff7c8 rdx: 0x rdi: 0x02a4 rsi: 0x0006 rbp: 0x7fff5fbff7e0 rsp: 0x7fff5fbff7c8 r8: 0x r9: 0x0001 r10: 0x7fff87e32412 r11: 0x0206 r12: 0x7fff5fbff7f0 r13: 0x000100225c50 r14: 0x000200016db0 r15
Re: Crashes in _Unwind_Resume
On Aug 25, 2010, at 3:15 AM, vincent habchi wrote: What compiler are you using? LLVM GCC 4.2, from Xcode 3.2.3 (1688.0/1691.0/1591.0). Best, Benjamin Rister ___ 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 in _Unwind_Resume
On Aug 25, 2010, at 10:48 AM, vincent habchi wrote: If you use plain GCC 4.2 instead, does it also crash? Well, it’s hard to say, since it doesn’t happen on demand. I’d have to make a new build and push it out to users to see if the reports stopped coming in. Do you have some experience that this is a compiler bug, or is it just a guess because it involves exception machinery? I would expect that LLVM’s exception handling is pretty well broken-in by now, considering the volume of Obj-C and C++ code that Apple has shipped using it so far. Which isn’t to say that that couldn’t be the problem, but I don’t want to annoy users by putting out a bunch of releases that apparently are unchanged while I blindly flail about behind the scenes, hoping something fixes it. Best, Benjamin Rister ___ 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: an oldie but a goodie: observing properties of collected objects
On Jun 17, 2010, at 10:02 PM, Ken Thomases wrote: Also, you could probably abstract it out into a custom class to facilitate array observing, if you really wanted it. Maybe somebody already has, for all I know. In fact, I put our implementation of this up on github last year: http://github.com/bdrister/DSReceptionist It requires blocks and GC, so not suitable for iOS use as-is, but now that blocks have made their way to iOS, somebody could retrofit old-school memory management into it if they needed and make it dual mode. Best, Benjamin Rister___ 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: Anything like -[performBlockOnMainThread:]?
dispatch_sync(dispatch_get_main_queue(), ^{
...
});
An important reminder to anybody using this technique: be careful doing
dispatch_sync to the main queue under GC. There’s a bug
(rdar://problem/7455071) that can cause objects to not be kept alive by the
block across that thread switch, leading to crashes and other bad things.
This is a workaround you can use instead of dispatch_sync:
void dsfixed_dispatch_sync(dispatch_queue_t queue, dispatch_block_t block) {
dispatch_block_t copiedBlock = Block_copy(block);
dispatch_sync(queue, copiedBlock);
Block_release(copiedBlock);
}
Since the problem only occurs with dispatching to the main queue, it might be
better to specialize it for that purpose, but we started using this before the
details on the bug were nailed down, so our workaround is still generic. Note
also if you’re rolling your own that -copy is not a workable substitute for
Block_copy in this case; you can still be nailed by the bug.
Best,
Benjamin Rister___
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
Debugging auto_zone_resurrection_error in Core Data using GCD
0x7fff874870c3 in +[NSUserDefaults(NSUserDefaults) standardUserDefaults] () #19 0x00010001fc18 in +[MyClass initialize] (self=0x100084d58, _cmd=0x7fff85309d28) #20 0x7fff80743535 in _class_initialize () ... The console only has this, which doesn’t seem related: Debug: _DSLookupGetProcedureNumber getpwuid = 3 Debug: _DSLookupQuery 3 status OK -- Benjamin Rister President, Decimus Software, Inc. http://decimus.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: Debugging auto_zone_resurrection_error in Core Data using GCD
Because this isn’t already thorny enough, let me note that adding a [startDate
self] below the dispatch_sync in the first example doesn’t fix the problem.
This shows that it’s surviving long enough to at least reach the
dispatch_sync() call, and in fact malloc_history shows this:
ALLOC 0x200028960-0x20002896f [size=16]: thread_102787000 |thread_start |
_pthread_start | __NSThread__main__ | -[MyThread main] |
-[__NSOperationInternal start] | -[MyOperation main] | +[NSDate date] |
+[__NSCFDate __new:] | __CFAllocateObject |
_internal_class_createInstanceFromZone | auto_zone_allocate_object
FREE 0x200028960-0x20002896f [size=16]: thread_102787000 |thread_start |
_pthread_start | __NSThread__main__ | -[MyThread main] |
-[__NSOperationInternal start] | objc_collect | auto_collect |
Auto::ThreadLocalCollector::collect(bool) |
Auto::ThreadLocalCollector::process_local_garbage(bool) |
Auto::ThreadLocalCollector::scavenge_local(unsigned long, unsigned long*)
In other words, it’s being collected after -main has returned, as part of
-[NSOperation start]’s cleanup.
Also new interesting data is that even in the -doThatThingTo:attachValue:
instances, the resurrected garbage pointer is still an NSDate from the *other*
example. So it seems like there’s some sort of a delayed response, like Core
Data is storing a weak-but-nonzeroing pointer to the NSDate somewhere, the
object is collected, and later mucking in the MOC exposes the dangling pointer.
I remain thoroughly mystified…
Thanks for any assistance,
Benjamin Rister
On Jan 26, 2010, at 10:57 AM, Benjamin Rister wrote:
I’m getting an auto_zone_resurrection_error from inside Core Data. Because
this is following switching from locking a MOC on different threads (which
was working fine) to dispatching blocks to a GCD queue, my suspicion
naturally tends towards a multithreading violation. However, I’ve been over
it a million times and just can’t find by inspection any cases of doing
anything in the MOC (including its MOs, obviously) besides on that queue.
Using the debug suffix when loading frameworks (to try to enable Core Data’s
multithreading asserts) dies elsewhere for no apparent reason, not to mention
that I don’t actually see a _debug version in Core Data.framework, nor see a
download to obtain one from connect.apple.com like there was for 10.5.
However, there’s also a suspicious trend in the places that this happens of
it appearing that an object assigned to a local variable or method parameter
outside of a dispatch_sync() is being collected before its use in the block.
In other words, the block’s reference may not be keeping the object alive.
For instance:
- (void)main {
NSDate* startDate = [NSDate date];
/* lots of stuff */
dispatch_sync(dispatch_get_main_queue(), ^{
if(![self isCancelled]) {
MyManagedObject* myMO = self.aRelationship.itsMO;
ourItem.numericalValue = /* a number; this works fine,
so it seems the MO is okay*/;
ourItem.aDate = startDate; /* problem occurs here, and
Instruments suggests startDate is the resurrected pointer */
/* ... */
}
});
}
So,
- What’s the current mechanism for enabling Core Data’s multithreading
asserts?
- Is there a typical, non-multithreading cause for
auto_zone_resurrection_errors inside Core Data?
- Or, are there any known bugs with GC and blocks (or a bug of mine in the
code snippet I gave) causing this?
Some more details, if needed:
malloc: resurrection error for block 0x2000281c0 while assigning
0x20003aa00[40] = 0x2000281c0
garbage pointer stored into reachable memory, break on
auto_zone_resurrection_error to debug
(gdb) bt
#0 0x7fff8862dc44 in auto_zone_resurrection_error ()
#1 0x7fff88628f09 in check_resurrection ()
#2 0x7fff8862adac in auto_zone_set_write_barrier ()
#3 0x7fff80749625 in objc_assign_strongCast_gc ()
#4 0x7fff80251104 in -[NSManagedObject(_NSInternalMethods)
_newPropertiesForRetainedTypes:andCopiedTypes:preserveFaults:] ()
#5 0x7fff80251deb in -[NSManagedObject(_NSInternalMethods)
_newAllPropertiesWithRelationshipFaultsIntact__] ()
#6 0x7fff80251d4e in
-[NSManagedObjectContext(_NSInternalChangeProcessing)
_establishEventSnapshotsForObject:] ()
#7 0x7fff80251c00 in _PFFastMOCObjectWillChange ()
#8 0x7fff80251b15 in _PF_ManagedObject_WillChangeValueForKeyIndex ()
#9 0x7fff802519d2 in _sharedIMPL_setvfk_core ()
#10 0x7fff80255a0e in _svfk_3 ()
#11 0x0001fd0e in __-[MyOperation
doThatThingTo:attachValue:]_block_invoke_1 (.block_descriptor=0x1006c6440)
#12 0x7fff82873f98 in _dispatch_barrier_sync_f_slow_invoke ()
#13 0x7fff8285287a in _dispatch_queue_drain ()
#14 0x7fff82853127 in _dispatch_queue_serial_drain_till_empty ()
#15
Re: Big memory/time consumption in NSTreeController KVO GC
On Dec 8, 2009, at 4:35 PM, Greg Parker wrote: Which OS version is this? 10.6.2 fixed a performance problem with garbage collection and large KVO populations. If you still have trouble in 10.6.2+ then you should file a bug report. On Dec 8, 2009, at 6:38 PM, Rob Keniger wrote: Please see my bug report rdar://7139579 which includes a simple sample project. The performance on Snow Leopard is orders of magnitude slower than in 10.5. As this is on 10.6.2, I’ve filed rdar://problem/7456424, referencing Rob’s report. ...and I should point out that these issues were bad enough for me to completely abandon NSTreeController for my own lightweight tree controller class. I've never looked back, I spent m0re hours struggling with NSTreeController than I care to think about. Considering the other issues I’m having with it, I suspect I’m headed down the same path. For the record, this will be three for three times I’ve tried to use NSTreeController in one of our apps and have been unable to do so. Thank you, Greg and Rob, for your input. Maybe a fix for this can make 10.6.3, with any luck. Best, Benjamin___ 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: NSOutlineView expand-by-default with NSTreeController
On Dec 5, 2009, at 6:11 PM, Jason Foreman wrote: [[treeController arrangedObjects] childNodes]; Iterate over this collection and find nodes where [node representedObject] is equal to your newly inserted objects. Then you can pass this NSTreeNode instance to -[NSOutlineView exandItem:]. This isn't terribly clean, and it might fall down if you have a large number of items in your tree controller, but it works for what I need and might work for you. Thanks, Jason. Unfortunately, the content can still be fairly large, so I’m not sure about how the performance of a brute force method like this will be. On the other hand, premature optimization is the root of all evil, and this is really easy to implement. It might not be a bad idea to just do this for now, don’t worry about the inefficiency, see how it works for the content sizes that a human could deal with, and just revisit the question if it ends up being a practical problem. So if anybody has a cleaner solution (which I’m guessing by the silence they don’t), I’m all ears. Otherwise I’ll try this, and just fall back to rewriting NSTreeController myself if the performance doesn’t work out. (Is there any open source NSTreeController reimplementation out there?) Best, Benjamin Rister___ 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
Big memory/time consumption in NSTreeController KVO GC
I have a NSTreeController displayed via an NSOutlineView. It’s set up to expand items by default as they’re added to the model. This is all on Snow Leopard. When a bunch of items (some thousands) are added and removed from the model, there’s a large memory spike (multi-hundred MB) almost entirely of Malloc 16.50 KB blocks, and the bulk of the CPU time is being spent in libauto. The stack trace of most of the memory allocations is: ... 12 libSystem.B.dylib _dispatch_call_block_and_release 11 libauto.dylib auto_collection_work(Auto::Zone*) 10 libauto.dylib auto_collect_internal(Auto::Zone*, unsigned int) 9 libauto.dylib Auto::Zone::collect(bool, void*, unsigned long long*) 8 libauto.dylib weak_call_callbacks 7 Foundation NSKeyValueObservanceBecameUseless 6 Foundation _NSKeyValueRemoveUselessObservances 5 Foundation _NSKeyValueObservationInfoCreateByCollecting 4 Foundation -[NSKeyValueObservationInfo _initWithObservances:count:] 3 Foundation -[NSConcretePointerArray addPointer:] 2 libauto.dylib auto_assign_weak_reference 1 libauto.dylib weak_register 0 libauto.dylib append_referrer_no_lock(weak_referrer_array_t*, void**, auto_weak_callback_block*) Almost all of the rest are: ... 21 MyProject -[MyModelObject addChild:] 20 Foundation NSKVOInsertObjectAtIndexAndNotify 19 Foundation -[NSObject(NSKeyValueObserverNotification) didChange:valuesAtIndexes:forKey:] 18 Foundation NSKeyValueDidChange 17 AppKit -[NSTreeControllerTreeNode observeValueForKeyPath:ofObject:change:context:] 16 AppKit -[NSTreeControllerTreeNode updateChildNodesForKeyPath:affectedIndexPaths:] 15 AppKit -[NSTreeControllerTreeNode updateChildNodesForKeyPath:affectedIndexPaths:] 14 Foundation -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] 13 Foundation NSKeyValueDidChange 12 Foundation -[NSKeyValueNestedProperty object:withObservance:didChangeValueForKeyOrKeys:recurse:forwardingValues:] 11 Foundation -[NSObject(NSKeyValueObserverRegistration) addObserver:forKeyPath:options:context:] 10 Foundation -[NSObject(NSKeyValueObserverRegistration) _addObserver:forProperty:options:context:] 9 Foundation -[NSKeyValueUnnestedProperty object:didAddObservance:recurse:] 8 Foundation -[NSKeyValueNestedProperty object:didAddObservance:recurse:] 7 Foundation -[NSObject(NSKeyValueObserverRegistration) addObserver:forKeyPath:options:context:] 6 Foundation -[NSObject(NSKeyValueObserverRegistration) _addObserver:forProperty:options:context:] 5 Foundation _NSKeyValueObservationInfoCreateByAdding 4 Foundation -[NSKeyValueObservationInfo _initWithObservances:count:] 3 Foundation -[NSConcretePointerArray addPointer:] 2 libauto.dylib auto_assign_weak_reference 1 libauto.dylib weak_register 0 libauto.dylib append_referrer_no_lock(weak_referrer_array_t*, void**, auto_weak_callback_block*) After every item is eventually removed (aside from one remaining one in the root, which was already there at the start), the app is still using 48MB RPRVT. This was 6MB at the start of the process, in this same model state as it ended. heap -guessNonObjects shows most of the memory as non-objects in dictionaries and arrays (e.g. NSCFDictionary[48]), and NSConcretePointerArrays, all in the auto zone. The only references to some of these key function names I could find on the web were in the libauto sources, and no mention at all in mailing lists, so it doesn’t seem like anybody else has posted about this before. Any ideas about why NSTreeController’s KVO is taking up so much memory/CPU with bookkeeping? Any suggestions for working around the problem? Thanks, Benjamin Rister___ 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: Big memory/time consumption in NSTreeController KVO GC
On Dec 8, 2009, at 2:44 PM, jonat...@mugginsoft.com wrote: Any ideas about why NSTreeController’s KVO is taking up so much memory/CPU with bookkeeping? Any suggestions for working around the problem? I assume that you are using bindings. Yes. Looks like a typical KVO notification storm to me. What works well for adding and updating one or two objects can easily turn to sludge for larger object numbers as thousands of KVO notifications are sent. This isn't bookkeeping - its KVO doing what you asked it to do - telling you about every change to your model. Well...not quite. There’s nothing about doing this notification that requires allocating hundreds of megabytes of overhead, particularly when the model itself is a fraction of that size, including payload. As I mentioned, these blocks it’s allocating are 16KB each. I can’t fathom what legitimate data you could possibly keep to do this observation that would take up that much space. In addition, if you look at the stack trace, most of the memory allocations are happening in response to NSKeyValueObservanceBecameUseless; thus, it’s happening after all of the actual, real work is done. It’s entirely speculation, but this could be explained by transient KVO stuff not being garbage collected properly, like it’s being kept alive unnecessarily. Also, while I forgot to mention this in the original email, the allocations follow a sawtooth pattern with a period of around 1-2 minutes, rising steadily then suddenly vanishing in an instant. This could support the GC hypothesis, or just be a red herring. Maybe these allocations are being missed by the generational collector for some reason, and are only caught by exhaustive collections? Or maybe some structure/cache/buffer is being periodically flushed, dropping the references? The model objects are gone (obviously, since that’s what triggers the allocations), so it shouldn’t be me keeping them alive. Are you adding your nodes to the NSTreeControllers content while bindings are active? If you build your tree separately and then set the NSTreeController content/binding then things should improve drastically. Unfortunately, this isn’t static content. It’s dynamic, and needs to change in response to external conditions. So the KVO notifications themselves are necessary in this approach, the overhead just seems unreasonable. Best, Benjamin___ 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
NSOutlineView expand-by-default with NSTreeController
I have an NSOutlineView in which I would like to have newly-appearing items be expanded by default. (It would be nice if NSOutlineView had support for this built in; rdar://problem/7421928.) The list archives and a web search reveal a couple hacks to try and make this work, but they depend on feeding the data to the outline view via the NSOutlineViewDataSource protocol so that they can ask for an expansion either at the time of insertion or in response to the outline view asking about the new pieces of data. I’m using NSTreeController, which makes the situation difficult as the actual “items” the outline view knows about aren’t anything I create myself, so I can’t really queue up an expansion of items as I insert them in the model, nor will the outline view ask me about the new data as it’s getting it from NSTreeController. It would be unfortunate to have to reimplement all of the NSTreeController functionality I’m using just to get a hook to do this, so does anybody know a way to get expand-by-default while still using NSTreeController and bindings? This code requires 10.6, so newfangled API is just fine. Thanks, Benjamin Rister___ 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
New AquaticPrime home on github
Following some discussion on the macsb list, I've created a new home for AquaticPrime, the popular open-source shareware registration infrastructure. http://github.com/bdrister/AquaticPrime The code has been stagnating since Lucas moved on, and many developers have their own private branches and extensions, so the hope is that under a new maintainer, these changes can make their way back into the core code so everybody can benefit from them. I've made a few updates/fixes already, and will contribute Decimus's AquaticPrime-related code when I get the chance, but I would like to encourage other AquaticPrime users to also contribute back to the project as they are able. For instance: - If you've fixed bugs, create a fork on github with them and I'll merge them back into the main trunk. Or, if you're not gitty, email me a patch for HEAD, or the changed files. - If you have extensions or helpful utilities, consider contributing them too. For instance, I'll be contributing Spotlight to automatically install the license file code, and I know some others have code to take normal license codes and ping a server for the license file, which I hope they'll contribute. - Open issues on github for problems you find or ideas you have, even if you don't know how to fix them. - Fix issues people file on github, if you do know how to fix them. - Contribute to updated documentation on the wiki. With your help, hopefully this already valuable project will continue to grow and improve in the upcoming years. Best, Benjamin Rister -- Benjamin D. Rister Decimus Software, Inc. http://decimus.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: NSUndoManager vs @synthesize
Pierre Bernard wrote: Do I still need to write my own accessors in order to perform NSUndoManager registration? Could my model objects observe themselves and register undoable changes in observeValueForKeyPath:ofObject:change:context: ? How does CoreData go about registering changes with the undo manager? Is this done by @synthesize setter or by the NSManagedObjectContext watching the model objects? Is it bad etiquette to do a ping on somebody else’s post? =) I too would really like to hear what the current best practices are for our brave new world of declared properties and synthesized accessors. Does anybody have any experience/suggestions they can share? Best, Benjamin Rister___ 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: NSImage with multiple representation sizes
Hi Ken, Thanks for your response. The size of an image is the default size of the rect in which it's drawn when the person drawing it doesn't have any more specific information. That's a concept that there can only be one of for the entire image, so it's confusing if the -size for contained reps doesn't match that of the image itself. I'm not concerned/confused about the results of -[NSImage size], I know it'll draw wherever I ask it to in whatever space that is. The -size is unrelated to the number of pixels in a rep. The ratio determines resolution. Reps can definitely have different numbers of pixels. The issue/question comes from tiffutil's explicit warning that NSImage doesn't like it or may be confused if the net sizes of the different representations in the tiff are different. So the reps can have different numbers of pixels, but if the dpi is the same across the different reps, they have different real sizes, and man tiffutil says that that is a problem. So it's perfectly fine to pack in different representations with different numbers of pixels. What the docs encourage is setting the metadata so that the -size of each representation is the same. man tiffutil says that NSImage may not be able to successfully choose the right size image out of the generated TIFF file. That sounds much stronger to me than encouraging it so that -size isn't potentially confusing to a programmer calling it. I'm not questioning whether what you say about the frameworks is true, just making sure we're on the same page, because you said the doc says one thing and that's not what I read in it. =) So to be clear: if I create a TIFF image, with tiffutil -cat, that has 9x...@72dpi, 16x1...@72dpi, 32x3...@72dpi: - This is an entirely supported configuration, despite what man tiffutil says and the warning it generates. - NSImage will correctly choose and draw representations now and in the future when drawn at different sizes, and both at 1.0 and non-1.0 scale factors. For instance, it will use the 32x3...@72dpi rep to fill a 16x16pt space at scale 2.0, even though the 16x1...@72dpi is the one that matches the physical size, despite the NSImage docs only giving rules based on color space, dpi, and bit depth for choosing representations. Is this correct, and something I can safely rely upon? Thanks, Benjamin Rister ___ 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: NSImage with multiple representation sizes
So to be clear: if I create a TIFF image, with tiffutil -cat, that has 9x...@72dpi, 16x1...@72dpi, 32x3...@72dpi: - This is an entirely supported configuration, despite what man tiffutil says and the warning it generates. No, these reps would not have the same -size. If you set the DPI metadata for the reps to 72, 128, and 256 respectively, then each rep would have -size 9x9. This is what I meant above. It's fine to have different pixel sizes, but it's best to set the metadata so that the -size is consistent. Okay, take 2 then. If I do the same thing, with 9x...@72dpi, 16x1...@128dpi, and 32x3...@256dpi (so the tiffutil warning isn't applicable anymore), will NSImage correctly use the more detailed image when drawing into a 16x16pt space? As I mentioned, Cocoa Drawing Guide Images How an Image Representation Is Chosen gives rules to be applied in the order of color space, dpi, bit depth. All have the same color space, the 9x...@72dpi matches dpi (when at 1.0 scale factor) and the others don't, so according to the docs it's the one that would be chosen, with poor results. Best, Benjamin Rister ___ 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
NSImage with multiple representation sizes
(Apologies if this ends up a duplicate…I sent the original over a week ago, and as far as I can see it's not in either Apple's or Cocoabuilder's archives, so I don't see any other explanation besides it just being eaten by something.) The core question: Is it still the best practice to have conceptually same images of different sizes in different files, e.g. Foo9x9.tiff, Foo32x32.tiff? icns isn't an option because they aren't all the standard icns sizes, and several places in the docs seem to discourage lumping them together (e.g. with tiffutil) anyway. The details: We have several images that are displayed at different sizes at various places in an application. Our artist has generated several bitmaps for these different scales. Modeling on the concept of an .icns file, my inclination would be to try and lump them all together in one multi-representation file and let NSImage figure out what the best representation is to draw from at any given point. This not only is convenient for the various usages around the app, but also for resolution independence (...maybe...see below). However, man tiffutil says: -cat allows combining multiple TIFF files into one. ... If the real sizes (pixel size divided by dpi) of the images being combined are not the same, a warning will be generated. This makes sure that NSImage can successfully choose the right size image out of the generated TIFF file. And Cocoa Drawing Guide: Images, How an Image Representation Is Chosen gives rules about color space, dpi, and bit depth, but there's no rule about choosing representations based on size. (But there's icns, right? How is that supposed to work, then?) I'm also concerned for resolution independence that the system might not choose the 32x32px rep to fill a 16x16pt space at a 2x scale factor, because everything I've seen in the resolution independence docs only talks about representations with different dpi. It would be rather inelegant to have to have multiple representations with the same pixels and just different metadata. So between the resolution independence concern, and the docs seemingly discouraging having different sized images in one file, this raises the core question above. What's the best way to arrange this for both drawing the image at different sizes in different places and resolution independence? Best, Benjamin Rister___ 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
NSImage with multiple representation sizes
The core question: Is it still the best practice to have conceptually same images of different sizes in different files, e.g. Foo9x9.tiff, Foo32x32.tiff? icns isn't an option because they aren't all the standard icns sizes, and several places in the docs seem to discourage lumping them together (e.g. with tiffutil) anyway. The details: We have several images that are displayed at different sizes at various places in an application. Our artist has generated several bitmaps for these different scales. Modeling on the concept of an .icns file, my inclination would be to try and lump them all together in one multi-representation file and let NSImage figure out what the best representation is to draw from at any given point. This not only is convenient for the various usages around the app, but also for resolution independence (...maybe...see below). However, man tiffutil says: -cat allows combining multiple TIFF files into one. ... If the real sizes (pixel size divided by dpi) of the images being combined are not the same, a warning will be generated. This makes sure that NSImage can successfully choose the right size image out of the generated TIFF file. And Cocoa Drawing Guide: Images, How an Image Representation Is Chosen gives rules about color space, dpi, and bit depth, but there's no rule about choosing representations based on size. (But there's icns, right? How is that supposed to work, then?) I'm also concerned for resolution independence that the system might not choose the 32x32px rep to fill a 16x16pt space at a 2x scale factor, because everything I've seen in the resolution independence docs only talks about representations with different dpi. It would be rather inelegant to have to have multiple representations with the same pixels and just different metadata. So between the resolution independence concern, and the docs seemingly discouraging having different sized images in one file, this raises the core question above. What's the best way to arrange this for both drawing the image at different sizes in different places and resolution independence? Best, Benjamin Rister ___ 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: Comparing NSImages
On Jul 23, 2009, at 5:19 PM, Nick Zitzmann wrote: Considering that there are several different variations on the TIFF file format (e.g. big-endian vs. little-endian, 0 is black vs. 1 is black, and then there's metadata), this would not surprise me. Yeah, that's what I expected, thanks. On Jul 23, 2009, at 5:39 PM, Greg Guerin wrote: Subtract the test's output image from the reference image, pixel by pixel, and look for any non-zero differences. This assumes compatible representations and no differences introduced by any other image-handling steps (e.g. device-RGB is device-dependent, so can't be assumed to be unvarying). Even so, you might encounter small non-zero differences that originate from outside your code-under-test. If these are larger than +/-1 they could be significant; +/-1 I'd probably accept as within the margin-of-error for rounding. Thanks, I didn't know if there was a cleaner way than doing it pixel- by-pixel myself; the info on reasonable tolerances is also quite helpful. I've tracked down the problem using this method (unfortunately, can't yet write about the issue here for the archives); thanks to everybody for their help. Benjamin Rister ___ 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
Comparing NSImages
We're having problems where the same code is producing corrupt output on certain OS versions but not others. We're trying to track this down, but are running into issues trying to verify intermediate results in the process, in particular NSImage data. Question 1: Is it normal for [NSImage TIFFRepresentation] to differ from release to release on identical images? There are pieces of very basic code [1] that are producing NSImages with different TIFFRepresentations on the same input on the different OSes, so I'm not convinced that's a reliable way to tell whether it's producing the expected output. Question 2: Assuming TIFFRepresentation isn't unique, what's the best practice to verify programmatically, say in a unit test, that the output matches an expected output? Thanks, Benjamin Rister [1] Very basic code: // input is NSImage* img, identical on both OSes (TIFFRepresentation exactly identical) int height = [img size].height; int width = [img size].width; NSBitmapImageRep *imageRep = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:NULL pixelsWide:width pixelsHigh:height bitsPerSample:8 samplesPerPixel:3 hasAlpha:NO isPlanar:NO colorSpaceName:NSDeviceRGBColorSpace bytesPerRow:width * 3 bitsPerPixel:24]; NSImage *newImage = [[NSImage alloc] init]; [newImage addRepresentation:imageRep]; [imageRep release]; [newImage lockFocus]; NSRect imgRect = NSMakeRect(0,0,width,height); [img drawInRect:imgRect fromRect:imgRect operation:NSCompositeSourceOver fraction:1.0f]; [newImage unlockFocus]; // output [newImage TIFFRepresentation] is different on the different OSes ___ 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: Large Core Data memory allocations for small rows
If you can reproduce this in a sample project with your model, you should definitely file a bug. If you can attach your program and steps to reproduce, you could file a bug with that as well. I've filed Radar 6480291 with the app, user's data file, and instructions. For the archives, following further followup from Ben, this one's now resolved. No bug in Core Data here, just the mix of the unfortunate way Instruments displays NSManagedObject allocations and the way our particular model, classes, and project are structured resulted in me looking in the wrong classes for the rogue ivars. D'oh. They've now been discovered and eradicated, and memory usage has returned to sane levels. Benjamin Rister ___ 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: Large Core Data memory allocations for small rows
Hi Ben, Thanks for the response. I'm rearranging your email a bit to respond to pertinent bits in one place: The stack trace is: 5 our code 4 CoreData -[_NSFaultingMutableSet objectEnumerator] 3 CoreData -[_NSFaultingMutableSet willRead] 2 CoreData -[NSManagedObjectContext(_NSInternalAdditions) _retainedObjectWithID:optionalHandler:withInlineStorage:] 1 CoreData + [NSManagedObject(_PFDynamicAccessorsAndPropertySupport) allocWithEntity:] 0 CoreData _PFAllocateObject This is allocating an object across a to-many relationship. Or the stack trace here could be computed incorrectly. If the stack trace were off slightly, then a hypothetically reasonable allocation would be for the CFSet holding the contents of the to-many relationship, assuming it had 50-100 thousand entries. The stack trace seems right to me, as far as I can tell. A to-many relationship set with the ~8K instances of this object in it has objectEnumerator called on it, and it's the first time this row data is ever accessed. There are ~6500 malloc instances back-to-back with this stack trace before it runs out of 32-bit VM and crashes, so it seems pretty clear that those are supposed to be the individual managed objects. It could be a bug in Core Data, or a memory smasher in your app that corrupts either our data structures or the ObjC runtime structures. malloc_history and libgmalloc (see man page) may help produce some more information. All of this information comes from analysis under Instruments, which is the same data malloc_history gives as far as I know. Our usual zombified runs produce no instances of bad memory hygiene of that sort, and I just ran the app under guard malloc and it produced no complaints until running out of VM (as expected). If you can reproduce this in a sample project with your model, you should definitely file a bug. If you can attach your program and steps to reproduce, you could file a bug with that as well. I've filed Radar 6480291 with the app, user's data file, and instructions. Thanks, Benjamin Rister ___ 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
Large Core Data memory allocations for small rows
We're running into a situation where Core Data is making very large memory allocations when faulting in small amounts of data. The entity has: - 2x Date - Int16 - 4x Int32 - Boolean - String - to-one relationship - String (in a subentity) - to-one relationship (in a subentity) - to-many relationship (in another subentity) The row in the SQLite database matches this structure, there's nothing unexpected there. And a database that contains about 8000 of them is a sum total of 1.1MB. But when these are faulted in, according to Instruments, Core Data allocates a GeneralBlock-528384 per record! Even if you naively preallocated a good chunk of memory for the strings, I can't imagine using more than 1-2KB per record, so 516KB is totally ridiculous. The stack trace is: 5 our code 4 CoreData -[_NSFaultingMutableSet objectEnumerator] 3 CoreData -[_NSFaultingMutableSet willRead] 2 CoreData -[NSManagedObjectContext(_NSInternalAdditions) _retainedObjectWithID:optionalHandler:withInlineStorage:] 1 CoreData + [NSManagedObject(_PFDynamicAccessorsAndPropertySupport) allocWithEntity:] 0 CoreData _PFAllocateObject I've checked instance variables in the NSManagedObject subclasses in case something silly was happening there, but with no luck. The class for these rows has a BOOL and 5 pointers, inheriting from a class with no ivars, inheriting from NSManagedObject. Any ideas/suggestions? Thanks, Benjamin Rister ___ 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
