Re: [Bibdesk-develop] Type info, bibitems, and thread safety

[Maxwell, A. R <ada...@pn...>]

On 02/01/10 15:14, "Christiaan Hofman" <cmh...@gm...> wrote:

> 
> On Feb 2, 2010, at 0:06, Maxwell, Adam R wrote:
> 
>> On 02/01/10 14:52, "Christiaan Hofman" <cmh...@gm...> wrote:
>> 
>>> I found a bug in the yaz framework (ZOOMRecord.m line 182). This one was the
>>> cause of a similar crasher in the ZOOM group server. Could it be that
>>> there's
>>> some bug in the ISI server and/or its services? Unfortunately I cannot test
>>> that.
>> 
>> That is certainly a bug, but looks like it would only cause a crash if you
>> used a local variable with the previous value from -renderedString after
>> asking for -rawString.
>> 
> 
> Or [NSDictionary dictionaryWithObjectsAndKeys:[record rawString],
> @"rawString", [record renderedString], @"renderedString", nil], versus the
> opposite order.

Yep, something like that could do it as well, depending on how the
initializer is implemented.

>> It's certainly possible that there's a bug in the ISI code, but I and others
>> had tested it pretty thoroughly (and it's the only search group I use).
>> 
> 
> When I pass the array of dictionaries, the logs say something like: "more
> significant bytes (108) than room to hold them", and nothing is received on
> the main thread. I haven't been able to find what can cause this useless
> message, but it has got something to do with (un)archiving.

NSDistantObjects that have been released at the remote end can result in
strange messages like this.  It sounds like type encoding isn't happy.