So, the good news is I think this IS a somewhat unusual circumstance that leads to this, but like my other testing recently, it may reveal a problem that would occasionally affect customers in ordinary circumstances.
To reproduce the bug, I set up -[IMBLibraryController reload] to automatically call itself again after 5 seconds. So for testing purposes, it's just constantly reloading the iMedia browser. I set a breakpoint at the exception point and after about 15 minutes of this I finally hit it!
It seems to be an issue with the identifier of some nodes not being canonical enough. Witness:
(lldb) po inOldNode
(IMBNode *) $1 = 0x0000000110ea0480 IMBNode (log)
identifier = IMBImageFolderParser://private/var/log
attributes = (null)
(lldb) po inNewNode
(IMBNode *) $2 = 0x000000010aadcba0 IMBNode (log)
identifier = IMBImageFolderParser://var/log
attributes = (null)
(lldb)
So iMedia's conception of the full path to the node in question has changed from /var/log to /private/var/log.
I don't know yet why it's so consistent most of the time and only "changes" on rare occasion. Will keep posted and if I find a fix, submit another pull request.
Daniel
On Mar 16, 2012, at 10:46 AM, Daniel Jalkut wrote:
> In my recent focus on eliminating some nagging bugs in iMedia, I've been using it a lot more than I usually do. Over the past couple days I've run into the exception here a few times:
> https://github.com/karelia/iMedia/blob/master/IMBLibraryController.m#...
> I can't predict when it will happen and it doesn't happen necessarily under very extreme circumstances. It just happened once after I compiled and ran the test app, on the initial scan.
> I just thought I would mention it in case anybody else has been seeing it and has ideas about what might lead to this condition.
> Daniel
