Closed pjrobertson closed 12 years ago
Interesting. There’s only one Scripting Bridge related call to setName:
and it’s immediately after the object should have been created. Those “object has not been added to a container yet” errors are pretty common with Scripting Bridge (believe me), but in my experience, it’s consistent. It either works or it doesn’t.
Any ideas how we can reproduce it? If not, it’s going to be pretty hard to narrow down.
Unfortunately I'm really not sure how it happened. I'll try and reproduce it, but I didn't even realise QS had crashed until about 2-3 hours after it happened, so it's not going to be easy.
Understood. Tell me this: Did you already have a playlist named “Quicksilver” when this happened? If no, did you have one after?
I'm pretty sure I had one before, and I do have one after. I'll keep trying, but it's looking unlikely that I'll be able to reproduce. Feel free to close this until I can get something more concrete.
On 19 February 2012 13:21, Rob McBroom < reply@reply.github.com
wrote:
Understood. Tell me this: Did you already have a playlist named Quicksilver when this happened? If no, did you have one after?
Reply to this email directly or view it on GitHub: https://github.com/quicksilver/Quicksilver/issues/702#issuecomment-4041848
I'm pretty sure I had one before, and I do have one after.
I suspect you did, in which case that setName:
call should never be reached. Here’s my theory. objectWithName:
didn’t get the playlist for some reason, so the plug-in tried to create a new one. Either the new empty playlist didn’t get created, or it did, but when trying to set the name, a playlist with that name already existed, so it complained.
Either way, the underlying problem is that the playlist wasn’t found, even though it exists. This is one of those weird things that can probably be fixed by calling get
on the thing early on, but I’m hesitant to to make changes without being able to test whether or not they make a difference.
Have to been able to reproduce this?
Nope. I will keep monitoring it, and will re-open the issue accordingly
Not entirely sure what I was doing, but it appears QS crashed due to an
NSInternalInconsistencyException
Attached (useful bits of) console log: P.S. ß65 (3921) is ß65 with #699 and #697 merged