Allison Newman
demal****@mac*****
Tue Apr 28 00:38:52 JST 2009
Actually, I discovered that my code doesn't work, although, as you say, it takes much longer to die. After my last message, I changed my annotated method to:
def annotated(tiles)
tiles.each do |tile|
check_cache(tile)
(0...100).each {puts "annotating:" + "#{tile.object_id.to_s(16)}/#tile.__ocid__} #{tile.respond_to?(:blank?)}"}
...
end
tiles
end
It blows up on the first attempt during the 100 times loop. One thing is sure, this is most definately a bug. I don't know if it's the same on your system, but on mine, the very first ruby-side proxy object that goes invalid ends up with a weird address. Here, I see addresses like 0x00210000, or there abouts for valid objects, and then, for the first dead object, this address moves dramatically to around 0x000E1800. After that, the rest of the dead objects are back in a 'normal' address range, but this first one is always at a strange, low, address. The version where the methods are defined every time the object crosses the bridge does however appear to be stable (or at least, I haven't found a way to break it yet)...
Anyway, I refuse to install RubyCocoa from source on my system (I need to make sure that my config matches that of my customers, so I always keep the standard Leopard install.) That, coupled with the fact that I don't have time to muck around in assembler, means that I can't go any further in the analysis. I do find it very worrying though. MacRuby can't get here fast enough!
On Monday, April 27, 2009, at 04:14PM, "Brian Marick" <maric****@examp*****> wrote:
>
>On Apr 25, 2009, at 4:35 AM, Allison Newman wrote:
>> Basically, if you manually cache the ruby side copy of the tiles,
>> the bug never happens: the object stays in the proxy cache. I've
>> included some modified code from Puzzle.rb that shows this.
>
>Your code does appear to work. It might be even more complicated,
>though. I made a version that returned all_tiles as a Ruby array,
>thinking that would retain each NSManagedObject's ruby-side proxy for
>the length of the drawRect. (After that, the array and all the proxies
>could be garbage-collected without harm. The next time the tiles were
>asked for, the proxies would have the singleton methods installed or
>reinstalled.) The code:
>
> def annotated(tiles)
> # as before.
> link_duration_of_contents_to_duration_of_container(tiles)
> end
>
> def link_duration_of_contents_to_duration_of_container(tiles)
> tiles.to_a
> end
>
>So this solution differs from yours in that I retain the array
>contents only for the duration of drawRect, instead of forever.
>
>My solution dies with the same "can't find isBlank" error. It takes
>much, much longer to happen, though.
>
>> For my money, it's a bug in RubyCocoa's cache handling routines.
>> Have you found any other classes that do this, other than
>> NSManagedObject?
>
>That's all I'm sure of. I have seen odd crashes with NSNotifications,
>though. I thought I understood the reason and had fixed the problem,
>but now I wonder.
>
>-----
>Brian Marick, independent consultant
>Mostly on agile methods with a testing slant
>www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>
>
>