On Jul 21, 2014, at 13:54, Russ McBride <russ...@gmail.com> wrote:
>
> I knew someone would have some magic goggles somewhere ;-)
>
> Hmmm... "Someone probably used the wrong fd somewhere". Not sure about this.
> I'm assuming that the wrong fd is not being used by BD's code anywhere. Or is
> there possibly an fd-handling issue with BD entry attachments?
I think my hypothesis fits this situation better. Suppose an object
@interface NSConcreteFileHandle : NSObject
{
id _state;
int _fd;
...
}
@end
My suspicion is that BD has a memory corruption bug somewhere, where that _fd
file descriptor is being overwritten; something like a double free, or extra
autorelease can do this, where a few bytes of this object end up freed or
reused for some other object. Thus, when -[NSConcreteFileHandle dealloc] is
sent, it tries to do close(_fd) on a value that's been fully or partially
overwritten with other bits.
This isn't the only crashing bug that's been reported which is really difficult
to reproduce. There's another one related to webview file icons.
> If it's caused by what otherwise would have been un-noted data corruption,
> then corruption of what-- the .bib data file?
Internal state of the program, which could include model data that is later
saved to disk. That's a worst-case scenario.
Adam
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
