Re: Sandboxing. WTF?
On May 27, 2012, at 22:40 , Graham Cox wrote: People will always click Allow if it gives them an easy life. Yes, and I think that's the potential weakness in Apple's sandbox-aware bookmark scheme. If you ask the user for permission, there's a good chance the user will just give it to you. I don't know of any solution to that, though I guess asking is better than not being forced to ask. Perhaps the app store review process takes note (or will take note) of such dialogs with the user, and rejects apps that seem to be asking for something egregious? ___ 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
Re: Sandboxing. WTF?
Le 28 mai 2012 à 07:18, Graham Cox a écrit : On 28/05/2012, at 3:10 PM, Marco S Hyman wrote: I think that is your issue. What is the issue? I have read that, several times. It states: With these provisos in mind, you can use a path-based temporary exception entitlement to gain programmatic access to the user’s ~/Library/Preferences folder. Use a read-only entitlement to avoid opening the user’s preferences to malicious exploitation. Well, that's what I am doing as I pointed out in my last message. But I still am unable to read the particular pref I need. (I have filed a radar asking that this feature be made available officially as well, but it's certainly a dupe). --Graham That's because you're not trying yo read ~/Library/Preferences/com.apple.iApps.plist but you are trying to read a preference file in your sandboxed application container. You just can't access file in ~/Library/Preferences using the CFPreferences API, as all calls to CFPreferences will be automagically redirected to you application container preferences folder instead. The posted documentation says: «A POSIX function, such as getpwuid, can provide the file system path you need.» I guess it means you have to resolve the real com.apple.iApps.plist path yourself and access the file directly. -- Jean-Daniel ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 6:54 PM, Jean-Daniel Dupas wrote: The posted documentation says: «A POSIX function, such as getpwuid, can provide the file system path you need.» I guess it means you have to resolve the real com.apple.iApps.plist path yourself and access the file directly. Okaaay That's a bit weird though, because you have to put the static file paths you want to access in your entitlements, but getpwuid is a function call, returning a path dynamically. Perhaps that path is actually static? Or do I call it and somehow register the entitlement on the fly? If so, how? It's documentation and commentary like this that is making it hard to adopt sandboxing. If they really want us to do it, why not spell it out instead of leaving us a trail of cryptic clues? --Graham ___ 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
Re: Losing memory
On Monday, 28 May 2012 at 03:20, Charlie Dickman wrote: My application is using (leaking) too much memory and eventually dies because no more can be allocated. I have used Instruments to measure the usage and leaks and have addressed those it told me about. Now, however, Instruments indicates that memory reaches a steady state (no more increases) yet the app continues to die for lack of memory. Does anyone know of a next step I can take to help track down this problem? One thing I always find helpful in situations like this is to use Instruments' Allocations template, then, ignoring the graph and byte counts, sort the Statistics view at the bottom by # Living and see if there's anything that seems to be allocated a surprising number of times. Often there are large numbers of small objects that are really just handles to other things - for example, objects holding on to memory-mapped files, or OpenGL textures. These objects don't contribute much to the Allocations count, because they themselves are very small. The things they're holding on to also don't contribute, because they're not 'allocated' in a way the instrument tracks, but they could be taking up a lot of your address space. Jamie. ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 5:23 PM, Graham Cox wrote: On 28/05/2012, at 6:54 PM, Jean-Daniel Dupas wrote: The posted documentation says: «A POSIX function, such as getpwuid, can provide the file system path you need.» I guess it means you have to resolve the real com.apple.iApps.plist path yourself and access the file directly. Okaaay That's a bit weird though, because you have to put the static file paths you want to access in your entitlements, but getpwuid is a function call, returning a path dynamically. Perhaps that path is actually static? Or do I call it and somehow register the entitlement on the fly? If so, how? It's documentation and commentary like this that is making it hard to adopt sandboxing. If they really want us to do it, why not spell it out instead of leaving us a trail of cryptic clues? --Graham The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to that absolute path. ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 7:31 PM, Roland King wrote: The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to that absolute path. That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 5:51 PM, Graham Cox wrote: On 28/05/2012, at 7:31 PM, Roland King wrote: The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to that absolute path. That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham Again I've not done this - just reading and attempting comprehension - but yes in this case that's what I think you have to do. The CFPreferencesCopyAppValue indirects through the file path mapper and goes to the local sandboxed version of ~/Library which doesn't have the preferences file in it. You could I suppose find the real one and copy it into the sandboxed location at the right place, then use the API to read it, that might work. Yes I know that would stink up the code somewhat and is not a long-term solution to the problem. I'm with you on having the API point being a much better way, Apple now has to decide whether or not allowing that kind of access is something they will sanction, then they'll fix the API point to allow it, or else they'll say no. I don't think there was a full understanding, until people started trying this stuff, how many applications on OSX do reach all over the filesystem looking at stuff and how many apps just won't sandbox whilst retaining full functionality. From my reading of the dev forums, and boy there are some frustrated people over there, they are still trying to come up with a way which works. I'd have a go see if you can even make the path and access the file at all first, then we'll know if we have decoded the tech note properly. ___ 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
Re: Sandboxing. WTF?
On 28 May 2012, at 07:58, Quincey Morris wrote: On May 27, 2012, at 22:40 , Graham Cox wrote: People will always click Allow if it gives them an easy life. I don't know of any solution to that, though I guess asking is better than not being forced to ask. Perhaps the app store review process takes note (or will take note) of such dialogs with the user, and rejects apps that seem to be asking for something egregious? The obvious solution to that problem, then, is to rebrand users as malware too, and restrict their access to the system accordingly. :) It is striking that the source for apps Apple has the most control over (the App Store), imposes the most fine-grained restrictions, whereas non-App Store apps is/will be, able to get away with mere code-signing. If sandboxing is meant to secure the user, as you suggest, by treating garden variety apps as malware, and relying on the user to grant privileges to user data, it seems counter-productive to rely on those restrictions for App Store-apps, which will be considered intrinsically trust-worthy by most users. As you point out, software can be malicious entirely within the remit of its intended functionality. Rather, I think, sandboxing exists to limit the impact of malicious code manipulating the ObjC-runtime environment, and to limit Apple's liability (legal and perceived) for attacks against apps it distributes. Mikkel ___ 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
Re: NSXMLParser and initWithStream
On 27 May 2012, at 7:14 PM, John Drake wrote: Looking at the documentation for NSXMLParser, it seems like the initWithStream: method to initialize a NSXMLParser would be the perfect solution to my problem. I can initialize the parser with a NSInputStream and then call the parse method on NSXMLParser whenever I receive data over my socket which should in turn call the NSXMLParser delegates. The documentation for -[NSXMLParser -initWithStream:] is sparse, but I see that the description is Initializes the receiver with the XML contents from the specified stream _and parses it_ [EA]. I guess that there should be no need to call -[NSXMLParser parse] on the incoming data; the whole point of hooking the parser up to a stream should be that you don't have to manage the stream yourself, right? However, I'm not seeing any of the delegates being called, the only method I see being called is the stream delegate stream:handleEvent:. I wonder if it's productive to make your ContentParser the delegate** of the input stream. It's the NSXMLParser that's interested in the incoming data. The convention in the Delegate pattern is that objects have at most one delegate. I do wonder why your setting of .delegate persists after you pass the stream into the parser. — F ** In Cocoa parlance, a delegate is an object that implements the methods of a delegate protocol (in this case your ContentParser is the delegate of the parser). The methods themselves are delegate methods. The latter term may be awkward, but delegate has to be saved for the object to which functionality is delegated. -- Fritz Anderson Xcode 4 Unleashed: Don't bring your bathroom copy into the kitchen — were you raised in a barn? http://x4u.manoverboard.org/ ___ 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
Re: Losing memory
On 27 May 2012, at 9:20 PM, Charlie Dickman wrote: My application is using (leaking) too much memory and eventually dies because no more can be allocated. I have used Instruments to measure the usage and leaks and have addressed those it told me about. Now, however, Instruments indicates that memory reaches a steady state (no more increases) yet the app continues to die for lack of memory. Does anyone know of a next step I can take to help track down this problem? How much memory does your allocation total plateau at? How do you know that it's exhaustion of memory that's getting you killed? I assume (you don't say) this is iOS, and that your problem is showing up on the device. What does the device's own log show? Is your app in the foreground or background at the time? Use the VM Tracker instrument and see if you're eating up memory in other zones. In my experience, your application heap (Allocations) can be stable, but if you accumulate Core Graphics/Core Animation buffers, you're in trouble pretty quickly. By default, VM Tracker snapshots the heaps only when triggered (Snapshot Now). It may be better if you check Automatic Snapshotting in the detail area for VM Tracker. — F ___ 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
Re: Page number in UIWebView
On Thu, May 24, 2012 at 6:49 PM, David Duncan david.dun...@apple.com wrote: On May 24, 2012, at 4:05 AM, Takeichi Kanzaki Cabrera wrote: Hello everyone, I'm displaying a PDF in an UIWebView object, is there a way to access the page number displayed when scrolling? Nope. OK, thanks, I was almost sure that this was the answer to my question ;-). In order to implement this functionality I create a subclass of UIWebView, the problem that I have now is that it works perfect on the simulator but not in a device, when I call stringByEvaluatingJavaScriptFromString: on the device with any value I get no answer, for example: [self stringByEvaluatingJavaScriptFromString:[NSString stringWithFormat:@window.scrollTo(0, %d), (pageNumber-1)*pageHeight]]; doesn't do anything, any clue? -- David Duncan -- Regards, Takeichi Kanzaki Cabrera Linux Registered User #308138 If you want to be original, be yourself. ___ 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
Re: CoreData, automatic migration and sandbox problems.
If you want to check whether a store needs to be migrated and ask the user, you
can use [NSPersistentStoreCoordinator metadataForPersistentStoreOfType:::] to
get the metadata for the document in question and [NSManagedObjectModel
isConfiguration:compatibleWithStoreMetadata:] to check whether that is
compatible with the current MOM.
A good place to do these checks is in NSDocumentController before attempting to
open the doc.
On 2012-05-28, at 9:59 AM, Samuel Williams wrote:
Hi,
I'm having trouble with automatic migrations and sandbox.
When the user opens an old file, the automatic migration fails due to no
write permission to the file.
-
(BOOL)configurePersistentStoreCoordinatorForURL:(NSURL*)url
ofType:(NSString*)fileType modelConfiguration:(NSString*)configuration
storeOptions:(NSDictionary*)storeOptions error:(NSError**)error
{
NSMutableDictionary *options = nil;
if (storeOptions != nil) {
options = [storeOptions mutableCopy];
} else {
options = [[NSMutableDictionary alloc] init];
}
[options setObject:[NSNumber numberWithBool:YES]
forKey:NSMigratePersistentStoresAutomaticallyOption];
[options setObject:[NSNumber numberWithBool:YES]
forKey:NSInferMappingModelAutomaticallyOption];
*//[options setObject:[NSNumber numberWithBool:YES]
forKey:NSReadOnlyPersistentStoreOption];*
BOOL result =
[super configurePersistentStoreCoordinatorForURL:url ofType:fileType
modelConfiguration:configuration storeOptions:options
error:error];
*//if (*error) {*
* // *** Fails here
*// [[NSAlert alertWithError:*error] runModal];*
*//}*
[options release];
return result;
}
Just wondering if anyone has a suggestion about how I can avoid writing to
the file, e.g. forcing the user to re-save or duplicate the document before
attempting the migration. It works fine for non-sandbox builds.
Kind regards,
Samuel
___
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/dave.fernandes%40utoronto.ca
This email sent to dave.fernan...@utoronto.ca
___
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
RE: NSXMLParser and initWithStream
I thought the same when I first read the documentation, and have tried not making ContentParser the delegate of the input stream as well as removing the call to -[NSXMLParser parse], however I still don't see any of the NSXMLParser delegates being called. I'm wondering if it's a run loop issue, and the delegates are not in the same thread the input stream and therefore don't get called? I don't know of any way to test which thread the stream is in or how to place the delegates in a different thread? Subject: Re: NSXMLParser and initWithStream From: fri...@manoverboard.org Date: Mon, 28 May 2012 07:44:16 -0500 CC: cocoa-dev@lists.apple.com To: smq...@hotmail.com On 27 May 2012, at 7:14 PM, John Drake wrote: Looking at the documentation for NSXMLParser, it seems like the initWithStream: method to initialize a NSXMLParser would be the perfect solution to my problem. I can initialize the parser with a NSInputStream and then call the parse method on NSXMLParser whenever I receive data over my socket which should in turn call the NSXMLParser delegates. The documentation for -[NSXMLParser -initWithStream:] is sparse, but I see that the description is Initializes the receiver with the XML contents from the specified stream _and parses it_ [EA]. I guess that there should be no need to call -[NSXMLParser parse] on the incoming data; the whole point of hooking the parser up to a stream should be that you don't have to manage the stream yourself, right? However, I'm not seeing any of the delegates being called, the only method I see being called is the stream delegate stream:handleEvent:. I wonder if it's productive to make your ContentParser the delegate** of the input stream. It's the NSXMLParser that's interested in the incoming data. The convention in the Delegate pattern is that objects have at most one delegate. I do wonder why your setting of .delegate persists after you pass the stream into the parser. — F ** In Cocoa parlance, a delegate is an object that implements the methods of a delegate protocol (in this case your ContentParser is the delegate of the parser). The methods themselves are delegate methods. The latter term may be awkward, but delegate has to be saved for the object to which functionality is delegated. -- Fritz Anderson Xcode 4 Unleashed: Don't bring your bathroom copy into the kitchen — were you raised in a barn? http://x4u.manoverboard.org/ ___ 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
RE: Sandboxing. WTF?
First off (as much as I agree with the sentiment) isn't WTF profanity? Second, and more to the point of my sentiment, and I hope someone on the Apple development team is reading this, have you people gone absolutely mad! This is MCP to the max! Thankfully I write apps for custom in-house applications so no big deal to me, but even if I had too, why in God's name would I distro via the app store, when I can simply setup an old fashioned download on an e-commerce site for my app?! Mark my words, to do this, will be the death of the App store. Users are fickle. make them irate and they WILL find a way around, and as several people have alluded to, user are notorious for clicking though (without reading or understanding) only to get what they want done. It's one thing to chroot an app on a server, where admins are the users, it's a WHOLE other idea to have no technical users dealing with app signing issues, et al... Perhaps instead of creating M$ like controls that have you clicking senselessly and endlessly to get something done, Apple should take a lesson from history. in other words, how many Windows, Linux, etc, users actually get hacked via downloaded applications VS. going to some malicious website that uses OS/browser level vulnerabilities (how does sandboxing prevent, for example, flashback)? When 99% of all security breaches in companies are as a result of a disgruntled employee (from the inside), or sabotage (from the inside) what does sand-boxing REALLY prevent? Nothing. It prevents nothing. It's nothing more then a warm fuzzy feeling, that actually makes things worse, because people start believing the hype, and relying on it as a method of security. So users become dumber, and take more risky action which then continues an ever tightening cycle (noose around the OS neck) of security, then one day, you go to log into your iMac and it asks for a blood sample. Boycott the App store I say, until Apple comes to its senses. Subject: Re: Sandboxing. WTF? From: my.inputstr...@googlemail.com Date: Mon, 28 May 2012 13:17:21 +0200 To: quinceymor...@rivergatesoftware.com CC: cocoa-dev@lists.apple.com On 28 May 2012, at 07:58, Quincey Morris wrote: On May 27, 2012, at 22:40 , Graham Cox wrote: People will always click Allow if it gives them an easy life. I don't know of any solution to that, though I guess asking is better than not being forced to ask. Perhaps the app store review process takes note (or will take note) of such dialogs with the user, and rejects apps that seem to be asking for something egregious? The obvious solution to that problem, then, is to rebrand users as malware too, and restrict their access to the system accordingly. :) It is striking that the source for apps Apple has the most control over (the App Store), imposes the most fine-grained restrictions, whereas non-App Store apps is/will be, able to get away with mere code-signing. If sandboxing is meant to secure the user, as you suggest, by treating garden variety apps as malware, and relying on the user to grant privileges to user data, it seems counter-productive to rely on those restrictions for App Store-apps, which will be considered intrinsically trust-worthy by most users. As you point out, software can be malicious entirely within the remit of its intended functionality. Rather, I think, sandboxing exists to limit the impact of malicious code manipulating the ObjC-runtime environment, and to limit Apple's liability (legal and perceived) for attacks against apps it distributes. Mikkel ___ 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/shashaness%40hotmail.com This email sent to shashan...@hotmail.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
Re: crashes loading saved file
Okay, so I'm back to trying to tackle this annoying unarchiving crash… Just to recap the problem: I get a exc_bad_access crash when unarchiving certain files from disk. The file is a keyed archive, which contains a fairly complex custom object graph, with plenty of circular references (i.e., parentNode --- childNode stuff). When this graph is relatively small I have no problems. But when it gets larger, it crashes. As mentioned previously, one seemingly significant thing about the crash is that the backtrace is 25,000 frames long. I've taken this to suggest that perhaps: A) some circular reference is getting stuck in a loop, or B) the graph is large enough that, while the unarchiver is trying to keep track of circular references, the stack overflows. I don't know if either of these possibilities makes sense, so I'm wondering how I might test for each? Partly because the massive backtrace isn't just a list of identical calls, and partly because the unarchiver is supposed to handle circular references, I kind of suspect B. But, if this is the case, how can I get around it? I already use archiveRootObject:toFile for archiving, so I would think I should be exploiting the built-in recursion checking stuff… Accordingly, I use unarchiveObjectWithFile to unarchive the graph. Everything I've done is pretty basic stuff, so perhaps my structure calls for a more advanced approach(??) I did include @autoreleasepool blocks in a couple of places, where temporary objects could be created during initialization. But that didn't help… So, I guess I'm wondering whether anyone else has had similar problems, and how you went about solving them. I should also mention that the file itself is very big - even a 13 MB file will cause the crash. By the way, it's not the super common failure to retain the unarchived object… Also, NSZombies and Guard Malloc don't show any obvious problems, and the static analyzer shows no memory errors. Any further thoughts greatly appreciated. J. James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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
Memory use
Is (Are) there functions that report application memory usage, as a whole, on the stack, in the autorelease pool, in the heap? Charlie Dickman 3tothe...@comcast.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sandboxing. WTF?
On 28 May 2012, at 4:30 PM, Shawn Bakhtiar wrote: First off (as much as I agree with the sentiment) isn't WTF profanity? Yes it is. Personally, I never use it, but I'll pass it unaltered to preserve mail threads or to quote accurately. Second, and more to the point of my sentiment, and I hope someone on the Apple development team is reading this, have you people gone absolutely mad! 1. Sentiment isn't really what a technical mailing list is about. It's for mutual technical assistance, not torches and pitchforks. 2. There are some people from Apple who read these lists. They do so in their spare time. They are not in a position to influence policy. They do not generate bug reports from postings (go to bugreport.apple.com and file a report yourself). They are often very helpful, and flooding them with sentiments will just drive them away. 3. You're waking up nearly a year late. Apple documented this requirement last June. Apple has already been subjected to all the sentiment anyone can muster, and has made sandboxing entitlements more flexible in response. Sentiment, without documented use cases and concrete (I will add _informed_) suggestions for improvement, won't accomplish anything at this late date. Thankfully I write apps for custom in-house applications so no big deal to me, but even if I had too, why in God's name would I distro via the app store, when I can simply setup an old fashioned download on an e-commerce site for my app?! Sandboxing isn't for everybody. Apple never said otherwise. As in so much of engineering, you choose your tradeoffs. If you can't sandbox, don't submit the app to the MAS. The tradeoff is that most developers don't have the resources to handle publicity, distribution, updates, or worldwide payments, and the MAS does those things for them. (You can afford time and money to do those things for yourself? Fine. Not everybody can eat cake.) The MAS makes more money for most developers. With sandboxing, it also provides customers more assurance than they otherwise would have that the apps they buy won't damage or steal their data. it's a WHOLE other idea to have no technical users dealing with app signing issues, et al... Eh? The app is signed by the developer. Apple countersigns it. The user never sees a signature, except that breaking a signature will break the app. As far as it goes, that's a good thing. how many Windows, Linux, etc, users actually get hacked via downloaded applications VS. going to some malicious website that uses OS/browser level vulnerabilities (how does sandboxing prevent, for example, flashback)? When 99% of all security breaches in companies are as a result of a disgruntled employee (from the inside), or sabotage (from the inside) what does sand-boxing REALLY prevent? Nothing. It prevents nothing. Sandboxing does not prevent determined attacks from hostile insiders. It is also COMPLETELY USELESS at promoting sound practices of regular oral hygiene. Suggesting a system is 100% useless if it isn't 100% miraculous is a strawman. My guess is that most of the real-world exposure Apple customers have is to Trojan applications, or applications that provide more capabilities to exploits than the apps themselves strictly need. Sandboxing an application mitigates the exposure through that app. Sandboxing isn't 100% miraculous. Individual developers will have perfectly legitimate reasons to do things that would be serious security holes if those things were allowed to everybody. Those legitimate features will be frozen out. The implementation will have bugs for years to come, and it is alarming that Apple saw nothing wrong with making it compulsory before completely thinking it out. Sandboxing can be an annoyance. But on its own terms, it's not an outrage. If you can't live with it, you're thrown back on distributing and selling your application yourself. Which is no worse than the position you were happy to be in a year ago. — F ___ 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
Re: Sandboxing. WTF?
On 29/05/2012, at 7:30 AM, Shawn Bakhtiar wrote: First off (as much as I agree with the sentiment) isn't WTF profanity? Well, it's in the eye of the beholder. I merely meant Where To Find (information) ;-) Mark my words, to do this, will be the death of the App store. Users are fickle. make them irate and they WILL find a way around, and as several people have alluded to, user are notorious for clicking though (without reading or understanding) only to get what they want done. It's one thing to chroot an app on a server, where admins are the users, it's a WHOLE other idea to have no technical users dealing with app signing issues, et al... Perhaps instead of creating M$ like controls that have you clicking senselessly and endlessly to get something done, Apple should take a lesson from history. in other words, how many Windows, Linux, etc, users actually get hacked via downloaded applications VS. going to some malicious website that uses OS/browser level vulnerabilities (how does sandboxing prevent, for example, flashback)? When 99% of all security breaches in companies are as a result of a disgruntled employee (from the inside), or sabotage (from the inside) what does sand-boxing REALLY prevent? Nothing. It prevents nothing. It's nothing more then a warm fuzzy feeling, that actually makes things worse, because people start believing the hype, and relying on it as a method of security. So users become dumber, and take more risky action which then continues an ever tightening cycle (noose around the OS neck) of security, then one day, you go to log into your iMac and it asks for a blood sample. Boycott the App store I say, until Apple comes to its senses. That isn't going to happen. I don't know about others' experiences with the App Store, but as an independent developer, it's been far more successful than we dared hope when it first opened. There's no way we could have done anywhere near as much business as we have, and withdrawing from it is only going to hurt us, not Apple. And that's if it even made sense to do so, which it doesn't - the horse is already out of the stable. If the App Store were launching tomorrow with this requirement such a boycott might stand a small chance. Sandboxing is a bit of a developer inconvenience, and while I tend to agree it really doesn't solve anything (or, it does, but the benefits are outweighed by the costs), it's not especially inconvenient for the user in the manner you're painting. In my case, assuming Apple are OK with the temporary exemptions to certain parts of the file system I'm asking for, the user will be none the wiser. In a few cases, where the user has put their iPhoto Library in a non-standard location, or has elected not to keep their photos in the iPhoto shoebox, I'll have to ask them if it's OK to peek at their iPhoto Library (or if their photos are all over the place, this would be unfeasible, so they'll just not be able to use that feature of our app). It's the usual 80/20% tradeoff - 80% of the users can be served without a hitch, leaving 20% with a few issues. Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. I'd have a go see if you can even make the path and access the file at all first, then we'll know if we have decoded the tech note properly. OK, back to the technical problem at hand. I have succeeded in getting this to work. I use getpwuid() to get the path to the user's home directory, append the standard location for the prefs file I want and I can read it into a NSDictionary (because I have the temporary exception privilege set). So that works alright - thanks for the help in getting me to understand what the documentation really is getting at. CFPreferencesCopyAppValue indirects through the file path mapper and goes to the local sandboxed version of ~/Library Yep, I see what's going on now. It's also why it was failing without a deny from sandboxd. What's annoying is that the parameters to this function give it enough information to realise that the intended file is outside of my sandbox (the fact that it's another app's ID) and could also isolate me in future from that app in itself being sandboxed. If iPhoto is sandboxed in future, its preferences will move and the getpwuid() technique will fail again. A correct fix to CFPreferencesCopyAppValue() would allow things to continue working seamlessly when that happens. Right now I have to look forward to my app breaking due to the fragility (and apparent lack of joined-up thinking) of this whole approach. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or
Re: Sandboxing. WTF?
On May 28, 2012, at 5:43 PM, Fritz Anderson wrote: The tradeoff is that most developers don't have the resources to handle publicity, distribution, updates, or worldwide payments, and the MAS does those things for them. (You can afford time and money to do those things for yourself? Fine. Not everybody can eat cake.) I’m not sure the “Let them eat cake” thing really works for the MAS, since: - MacUpdate provides the same type of “publicity” that the MAS provides (better, in fact, since you get bumped back to the top each time you release an update), and it’s free. - Updates can be handled by Sparkle, which not only is both free and easy to set up, but which, unlike the MAS’s update scheme, *actually works* — your users will find out about updates when they use your app, as opposed to the App Store’s update scheme where you never find out about an updated version of an app until you happen to go to the App Store for some reason. I don’t know about you, but I rarely go to the App Store, and when I do, there’s usually a bunch of ancient unapplied app updates in there that I didn’t know about. I doubt most end users regularly check the App Store to see if any of their apps need updating. - Worldwide payments are already handled by services such as Kagi, eSellerate, et al., and they’re usually quite a bit *cheaper* than the MAS. The MAS only gets price-competitive with Kagi if the price of your app drops below $3.50 or so. Anything above that, and Kagi will be significantly less expensive. The only thing that’s legitimately more expensive when going non-MAS is getting a website for distribution, and a) web sites are cheap, b) if you move any kind of volume at all, their price will be easily dwarfed by the savings from not paying the App Store 30% of profits, and c) really, even if you’re going MAS, you’re going to want to have a web site anyway. I’m not really seeing the “cake” in non-MAS software development. Charles ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 7:23 PM, Charles Srstka wrote: The only thing that’s legitimately more expensive when going non-MAS is getting a website for distribution, and a) web sites are cheap, b) if you move any kind of volume at all, their price will be easily dwarfed by the savings from not paying the App Store 30% of profits, and c) really, even if you’re going MAS, you’re going to want to have a web site anyway. Actually, looking around a bit more, it turns out that eSellerate is able to handle distribution as well. Doing so requires their “Premium” plan, which bumps their fees from 5.9% to 8.9%, but that’s still worlds cheaper than the MAS’s 30%. Cake indeed. Charles ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 7:59 PM, Graham Cox graham@bigpond.com wrote: Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. Uh, in 10.8 they implemented almost *exactly* the scheme Wil described: http://www.apple.com/macosx/mountain-lion/security.html --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sandboxing. WTF?
On 29/05/2012, at 10:40 AM, Kyle Sluder wrote: On May 28, 2012, at 7:59 PM, Graham Cox graham@bigpond.com wrote: Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. Uh, in 10.8 they implemented almost *exactly* the scheme Wil described: http://www.apple.com/macosx/mountain-lion/security.html Yes, but *as well as* sandboxing, not instead of. The current implementation of sandboxing is extremely clunky, full of holes, and solves no real problems. If it were revoked tomorrow, I can't believe anybody here would mourn it - honestly? G. ___ 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
Another sandboxing issue
I'm getting this logged in the sandboxed version of my app: app name(4041) deny file-write-data /Users/me/Library/Autosave Information/Unsaved app name Document.ext This appears to be when Lion's autosaves my untitled document. Seriously? Lion's own features don't even know when to use the sandbox. Does this imply I need to add this location to my temporary exceptions? Would that not apply to every doc-based app that supports autosave/versions? Joined-up thinking! --Graham ___ 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
Re: Another sandboxing issue
On May 29, 2012, at 8:54 AM, Graham Cox wrote: I'm getting this logged in the sandboxed version of my app: app name(4041) deny file-write-data /Users/me/Library/Autosave Information/Unsaved app name Document.ext This appears to be when Lion's autosaves my untitled document. Seriously? Lion's own features don't even know when to use the sandbox. Does this imply I need to add this location to my temporary exceptions? Would that not apply to every doc-based app that supports autosave/versions? Joined-up thinking! --Graham I believe I read something about that last week over in the good old dev forums. IIRC the poster believed the app worked ok, it just logged a load of rubbish like that to the logfile, does your app still actually work? Is it writing Autosaved documents to the sandbox or just not writing them at all? Either way around it's still a bug but it may or may not be critical. ___ 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
Re: Another sandboxing issue
On 29/05/2012, at 11:18 AM, Roland King wrote: I believe I read something about that last week over in the good old dev forums. IIRC the poster believed the app worked ok, it just logged a load of rubbish like that to the logfile, does your app still actually work? Is it writing Autosaved documents to the sandbox or just not writing them at all? Either way around it's still a bug but it may or may not be critical. It does appear to work correctly despite this. I have added an entitlement exception that shuts it up. I do see lots of responses on the sandboxing forum from Apple saying that various things are known bugs, but of course it's not Apple that are going to cop the stick for them when users are exposed to them. --Graham ___ 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
Re: crashes loading saved file
Hi Charlie, Thanks for the reply. Hmm… I wonder if it would be enough to just copy the objects that lead to circular references? I'll think about it… I agree that it would be worth a try, if only to determine whether the problem really is related to circular references. thanks, J. On 2012-05-28, at 6:29 PM, Charlie Dickman wrote: J, If it were my problem, even though keyed archiving is supposed to handle circular references, I would try eliminating the circular references and see if it made a difference (even if you have to duplicate objects multiple times as this would only, at this time, be a test). I have no credentials to validate this approach other than 35 years of professional programming experience. On May 28, 2012, at 6:14 PM, James Maxwell wrote: Okay, so I'm back to trying to tackle this annoying unarchiving crash… Just to recap the problem: I get a exc_bad_access crash when unarchiving certain files from disk. The file is a keyed archive, which contains a fairly complex custom object graph, with plenty of circular references (i.e., parentNode --- childNode stuff). When this graph is relatively small I have no problems. But when it gets larger, it crashes. As mentioned previously, one seemingly significant thing about the crash is that the backtrace is 25,000 frames long. I've taken this to suggest that perhaps: A) some circular reference is getting stuck in a loop, or B) the graph is large enough that, while the unarchiver is trying to keep track of circular references, the stack overflows. I don't know if either of these possibilities makes sense, so I'm wondering how I might test for each? Partly because the massive backtrace isn't just a list of identical calls, and partly because the unarchiver is supposed to handle circular references, I kind of suspect B. But, if this is the case, how can I get around it? I already use archiveRootObject:toFile for archiving, so I would think I should be exploiting the built-in recursion checking stuff… Accordingly, I use unarchiveObjectWithFile to unarchive the graph. Everything I've done is pretty basic stuff, so perhaps my structure calls for a more advanced approach(??) I did include @autoreleasepool blocks in a couple of places, where temporary objects could be created during initialization. But that didn't help… So, I guess I'm wondering whether anyone else has had similar problems, and how you went about solving them. I should also mention that the file itself is very big - even a 13 MB file will cause the crash. By the way, it's not the super common failure to retain the unarchived object… Also, NSZombies and Guard Malloc don't show any obvious problems, and the static analyzer shows no memory errors. Any further thoughts greatly appreciated. J. James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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/3tothe4th%40comcast.net This email sent to 3tothe...@comcast.net Charlie Dickman 3tothe...@comcast.net James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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
Re: crashes loading saved file
Thanks, Quincey. Well, I've revisited this problem many times over the past year, or so (obviously, not on a daily, or even weekly basis, but the problem has been lurking for a long time, unresolved). I've gone over the code in detail literally hundreds of times looking for the kind of problem you describe. In the parent/child relationships, the CbCMNode class has methods for addChild and addParent which specifically test for identity between the node being added and self, so that a node's childNodes array, for example, can never contain the node itself. Nevertheless, for the sake of thoroughness, I did just place the NSAsserts you recommended in encodeWithCoder, but to no avail. The only reason I've begun to even vaguely questioned the framework -- honestly, for the first time today -- is because I've read a number of threads today that talked about potential problems in NSKeyedUnarchiver when dealing with large, circular graphs -- one of which was actually posted by a developer from Apple (can't recall who now). Also, Mike Ash's discussions on the subject didn't help my confidence particularly... Further, the fact that the size of the archive is a reproducible factor in the crashes seems odd. The nature of the graphs is such that size shouldn't influence the topology in any significant way (at least not considering the size and complexity of some of the graphs that do load without problems). There may be more nodes in the larger graphs, but their connectivity is fundamentally the same as with small graphs. So any obvious problem, like adding self to a childNodes array, would almost certainly show up in a smaller graph as well. Having said that, it is a complex structure, so I'll go over it again… But in response to your general suggestion that I'm somehow immediately jumping to blaming the frameworks as a first course of action, that honestly couldn't be further from the truth. Again, if anybody has had a similar experience, or has any further thoughts, any help would be appreciated. J. On 2012-05-28, at 7:58 PM, Quincey Morris wrote: On May 28, 2012, at 15:14 , James Maxwell wrote: Just to recap the problem: I get a exc_bad_access crash when unarchiving certain files from disk. The file is a keyed archive, which contains a fairly complex custom object graph, with plenty of circular references (i.e., parentNode --- childNode stuff). When this graph is relatively small I have no problems. But when it gets larger, it crashes. As mentioned previously, one seemingly significant thing about the crash is that the backtrace is 25,000 frames long. I've taken this to suggest that perhaps: A) some circular reference is getting stuck in a loop, or B) the graph is large enough that, while the unarchiver is trying to keep track of circular references, the stack overflows. I don't know if either of these possibilities makes sense, so I'm wondering how I might test for each? Partly because the massive backtrace isn't just a list of identical calls, and partly because the unarchiver is supposed to handle circular references, I kind of suspect B. But, if this is the case, how can I get around it? I already use archiveRootObject:toFile for archiving, so I would think I should be exploiting the built-in recursion checking stuff… Accordingly, I use unarchiveObjectWithFile to unarchive the graph. Everything I've done is pretty basic stuff, so perhaps my structure calls for a more advanced approach(??) I did include @autoreleasepool blocks in a couple of places, where temporary objects could be created during initialization. But that didn't help… I think you're approaching this incorrectly. At best, you're stating the problem neutrally (is getting stuck in a loop) as if uncertain whether to blame the frameworks (NSKeyedUnarchiver specifically) or your own code. This is a mistake. You *must* assume that you're doing something wrong, *until and unless* you find specific evidence that the frameworks are at fault. It's not that there can't be bugs in Cocoa frameworks. There are plenty. Rather, the rationale is that classes like NSKeyedUnarchiver have been used innumerable times, while your code has been used successfully -- how many times? Next, it's not remotely credible that NSKeyedUnarchiver is designed to recurse in a way that could put 25,000 frame on the stack. This would mean, for example, that NSKeyedUnarchiver wasn't usable in background threads, which by default have a *very* small stack. Occam's Razor says that you have a bug in your code. My guess is, given the backtrace you originally posted, that you've somehow added an object to one of its own array instance variables. That could well put NSKeyedUnarchiver into an infinite tailspin. (This would not be parentNode --- childNode stuff. It would be claiming that an object is its own child, which is a relationship you can't expect unarchiving
Re: crashes loading saved file
On May 28, 2012, at 20:48 , James Maxwell wrote: The only reason I've begun to even vaguely questioned the framework -- honestly, for the first time today -- is because I've read a number of threads today that talked about potential problems in NSKeyedUnarchiver when dealing with large, circular graphs -- one of which was actually posted by a developer from Apple (can't recall who now). Also, Mike Ash's discussions on the subject didn't help my confidence particularly… But in response to your general suggestion that I'm somehow immediately jumping to blaming the frameworks as a first course of action, that honestly couldn't be further from the truth. I think I was referring to that inner voice that *tempts* you to blame, not any actual blaming. :) We're probably at the point where you need to start showing code, at least in a reduced version, for encodeWithCoder and initWithCoder. Incidentally, assuming each CbCMNode instance has a child array and a parent pointer, you aren't trying to to archive both, are you? I wouldn't expect that to work. ___ 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
Re: crashes loading saved file
I think I was referring to that inner voice that *tempts* you to blame, not
any actual blaming. :)
Sure, understood.
We're probably at the point where you need to start showing code, at least in
a reduced version, for encodeWithCoder and initWithCoder.
- (void)encodeWithCoder:(NSCoder *)aCoder
{
[aCoder encodeObject:eventKey forKey:@eventKey];
[aCoder encodeObject:value forKey:@value];
[aCoder encodeInt:type forKey:@type];
[aCoder encodeInt:state forKey:@state];
[aCoder encodeFloat:closure forKey:@closure];
[aCoder encodeInt:depth forKey:@depth];
[aCoder encodeInt:count forKey:@count];
[aCoder encodeFloat:probability forKey:@probability];
[aCoder encodeObject:schemaNode forKey:@schemaNode];
[aCoder encodeObject:parentNodes forKey:@parentNodes];
[aCoder encodeObject:childNodes forKey:@childNodes];
[aCoder encodeObject:targetNodes forKey:@targetNodes];
[aCoder encodeObject:targetEdgeCounts forKey:@targetEdgeCounts];
[aCoder encodeObject:sourceNodes forKey:@sourceNodes];
[aCoder encodeObject:superState forKey:@superState];
[aCoder encodeObject:subStates forKey:@subStates];
}
- (id) initWithCoder:(NSCoder *)aDecoder
{
if((self = [super init]))
{
eventKey = [[aDecoder decodeObjectForKey:@eventKey] retain];
value = [[aDecoder decodeObjectForKey:@value] retain];
type = [aDecoder decodeIntForKey:@type];
state = [aDecoder decodeIntForKey:@state];
closure = [aDecoder decodeFloatForKey:@closure];
depth = [aDecoder decodeIntForKey:@depth];
count = [aDecoder decodeIntForKey:@count];
probability = [aDecoder decodeFloatForKey:@probability];
schemaNode = [[aDecoder decodeObjectForKey:@schemaNode] retain];
parentNodes = [[aDecoder decodeObjectForKey:@parentNodes] retain];
childNodes = [[aDecoder decodeObjectForKey:@childNodes] retain];
targetNodes = [[aDecoder decodeObjectForKey:@targetNodes] retain];
targetEdgeCounts = [[aDecoder decodeObjectForKey:@targetEdgeCounts]
retain];
sourceNodes = [[aDecoder decodeObjectForKey:@sourceNodes] retain];
superState = [[aDecoder decodeObjectForKey:@superState] retain];
subStates = [[aDecoder decodeObjectForKey:@subStates] retain];
}
return self;
}
CbCMNode is a NSObject subclass, btw.
Incidentally, assuming each CbCMNode instance has a child array and a parent
pointer, you aren't trying to to archive both, are you? I wouldn't expect
that to work.
Well, yes, that's what happens. In fact, it's much hairier than that! There's
actually an array of parentNodes, not just one. It's a complex graph, as I
mentioned, not a straightforward tree (which would already contain mutual
parent/child references, it seems to me). In my structure, there are about
three dimensions of this kind of referencing, allowing me to move around the
graph in useful ways… It's encoding hierarchical musical structure, for a music
learning/generation algorithm, so there's a lot of complexity involved. As I
say, it loads fine with smaller files, and testing the structure after loading
indicates that it has been reconstructed properly. This is why I suspect
there's a problem with trying to keep track of all these relationships during
unarchiving, which NSKeyedUnarchiver does on the stack, afaik. There's an
interesting discussion on this here:
http://forum.soft32.com/mac/Archiving-large-graphs-part-II-ftopict44343.html
It's a very old thread, from 2004, but it does seem to be addressing similar
problems. And I think these cases are rare enough that Apple wouldn't
necessarily put a bunch of time into improving them… besides, Michael Ash's
comments seem to suggest that they really couldn't improve matters anyway,
within the overall design of the NSCoder model. I just wondered if, perhaps,
there was a way to get the whole thing to happen on the heap, rather than the
stack, so that it could complete successfully. It would be slow, but I could
deal with that for the time being (i.e., until I get my doctorate finished,
after which time I could rip it apart and try a different approach!).
I did try, btw, using encodeConditionalObject for parentNodes, sourceNodes, and
superState, all of which are CbCMNodes. But the structure was no longer intact
after trying this (parent connections gone), so I think I misunderstood how
conditional objects are supposed to work...
J.
James B Maxwell
Composer/Doctoral Candidate
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
___
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:
Re: Memory use
On May 28, 2012, at 3:20 PM, Charlie Dickman wrote: Is (Are) there functions that report application memory usage, as a whole, on the stack, in the autorelease pool, in the heap? Not easily-used ones. It's not something that processes other than diagnostic or admin tools usually care about. You can use the Instruments app, or command-line tools like 'heap' and 'leaks', to find this out. (Questions about those tools should go to the xcode-users list.) If you _really_ want to know what to call, the usual answer is to go look up the source to the 'top' tool in the Darwin open-source repository, since it's the main client of those APIs whose source is accessible. (Questions about those APIs would best be sent to the darwin-userlevel mailing list, not here.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: crashes loading saved file
On May 28, 2012, at 10:08 PM, James Maxwell wrote: Well, yes, that's what happens. In fact, it's much hairier than that! There's actually an array of parentNodes, not just one. It's a complex graph, as I mentioned, not a straightforward tree (which would already contain mutual parent/child references, it seems to me). In my structure, there are about three dimensions of this kind of referencing, allowing me to move around the graph in useful ways… I suspect this isn't a bug in Foundation, so much as a scaling limit that you've exceeded with the complexity of the object graphs you write out. You've inadvertently found a way to get the graph traversal done by the unarchiver to recurse to arbitrarily deep levels, by generating graphs that have arbitrarily long non-cyclic paths through them. I suggest writing out simpler object graphs. One place you can start is by _not_ archiving the back-pointers. You can reconstruct those in the -initWithCoder method. For example, after a parent node unarchives its array of children, it can call each child to tell it, in effect, who's your daddy? so the child can initialize its parent pointer. In general, look at your graph and figure out the minimum number of object relations you need to archive to reconstruct its structure. Then archive only those, and recreate the rest at load time. (Another possibility is to work around this by creating a pthread with a really huge stack size limit, and doing the unarchiving on that thread. But I bet it'll be slow. Your users would probably rather you simplified the object graph and made opening documents faster.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: crashes loading saved file
On May 28, 2012, at 10:51 PM, I wrote: In general, look at your graph and figure out the minimum number of object relations you need to archive to reconstruct its structure. Then archive only those, and recreate the rest at load time. I just had another thought. Are you using linked lists? I suspect those are rather bad for the unarchiver, since it's likely to end up recursing all the way down the list, resulting in O(n) stack depth. That is, during -initWithCoder: for an item in the list, it'll be asked to unarchive the next property, which ends up calling -initWithCoder: for the next item in the list, and so on until it hits the end and can finally unwind the stack. If so, it would be a lot more efficient for the archiver if you stored the list as an NSArray, since that allows it to instantiate one item at a time (breadth-first instead of depth-first, basically.) —Jens ___ 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
Re: crashes loading saved file
On May 28, 2012, at 15:14 , James Maxwell wrote: Just to recap the problem: I get a exc_bad_access crash when unarchiving certain files from disk. The file is a keyed archive, which contains a fairly complex custom object graph, with plenty of circular references (i.e., parentNode --- childNode stuff). When this graph is relatively small I have no problems. But when it gets larger, it crashes. As mentioned previously, one seemingly significant thing about the crash is that the backtrace is 25,000 frames long. I've taken this to suggest that perhaps: A) some circular reference is getting stuck in a loop, or B) the graph is large enough that, while the unarchiver is trying to keep track of circular references, the stack overflows. I don't know if either of these possibilities makes sense, so I'm wondering how I might test for each? Partly because the massive backtrace isn't just a list of identical calls, and partly because the unarchiver is supposed to handle circular references, I kind of suspect B. But, if this is the case, how can I get around it? I already use archiveRootObject:toFile for archiving, so I would think I should be exploiting the built-in recursion checking stuff… Accordingly, I use unarchiveObjectWithFile to unarchive the graph. Everything I've done is pretty basic stuff, so perhaps my structure calls for a more advanced approach(??) I did include @autoreleasepool blocks in a couple of places, where temporary objects could be created during initialization. But that didn't help… I think you're approaching this incorrectly. At best, you're stating the problem neutrally (is getting stuck in a loop) as if uncertain whether to blame the frameworks (NSKeyedUnarchiver specifically) or your own code. This is a mistake. You *must* assume that you're doing something wrong, *until and unless* you find specific evidence that the frameworks are at fault. It's not that there can't be bugs in Cocoa frameworks. There are plenty. Rather, the rationale is that classes like NSKeyedUnarchiver have been used innumerable times, while your code has been used successfully -- how many times? Next, it's not remotely credible that NSKeyedUnarchiver is designed to recurse in a way that could put 25,000 frame on the stack. This would mean, for example, that NSKeyedUnarchiver wasn't usable in background threads, which by default have a *very* small stack. Occam's Razor says that you have a bug in your code. My guess is, given the backtrace you originally posted, that you've somehow added an object to one of its own array instance variables. That could well put NSKeyedUnarchiver into an infinite tailspin. (This would not be parentNode --- childNode stuff. It would be claiming that an object is its own child, which is a relationship you can't expect unarchiving to deal with, if you think about the order in which things happen.) The backtrace even appears to tell you the class of the object that's doing this: CbCMNode. According to the backtrace, this object is unarchiving an array object key, and that unarchives an instance of CbCMNode, which unarchives … . You might have an easier time of detecting this during archiving, rather than unarchiving. How about you add something like this to [CbCMNode encodeWithCoder:]: NSAssert (![self-whateverArray containsObjectIdenticalTo: self], @Er, this shouldn't happen); Depending on the bug in your code, it might be a bit harder to find out where it's going wrong. However, as long as there's a small voice in your mind trying to throw the blame on the frameworks, you won't get anywhere. ___ 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
