[MacRuby-devel] 0.2 available for testing

Laurent Sansonetti lsansonetti at apple.com
Fri Jun 6 15:19:44 PDT 2008


On Jun 6, 2008, at 10:26 AM, Stephen Bannasch wrote:

> At 10:27 PM -0700 6/5/08, Laurent Sansonetti wrote:
>>>
>>> Ths is repeatable however the number of iterations before the crash
>>> varies.
>>>
>>> I don't understand why @layoutManger appears to be nil the whole  
>>> time.
>
> Laurence thanks for helping -- it's not that CircleView is that  
> important -- I'm using it as a way to familiarize myself with the  
> macruby architecture and the debugging tools.
>
>> So, I suspect the GC prematurely collect some ivars, including
>> @layoutManager.
>>
>> Fixing this problem is not easy, the bug is most probably in
>> variable.c. One thing i would do is to setup a breakpoint in
>> __rb_objc_finalize when *(Class *)obj == <the address of
>> NSLayoutManager>. Then, verify why there is no reference to that  
>> object.
>
> Excuse the simple questions ...
>
> I assume the breakpoint needs to be set in libmacruby.dylib in the  
> MacRuby.framework.
>
> What's the best way of doing this?
>
> Run CircleView from xcode and then attach with gdb from the shell,  
> find __rb_objc_finalize in the macruby dylib and insert a  
> breakpoint ...?

I would do the following:

$ gdb --args /Path/to/CircleView.app/Contents/MacOS/CircleView
[...]
 > b __rb_objc_finalize
 > p (void *)objc_getClass("NSLayoutManager")
[note the address]
 > condition 1 *(Class *)obj == [the given address]
 > r

>> The problem: I cannot reproduce this crash. And all people I asked
>> about also cannot reproduce it.
>>
>> So, I will try to reproduce the crash by writing a small similar test
>> case and stress the GC. In the meantime, I will still release 0.2
>> tomorrow.
>
> It certainly seems there might be something different in my  
> environment that is causing the issue.
>
> I just tried doing a Safe Boot and then logging in with the shift  
> key down (I think that should minimize the differences) and running  
> CircleView from xcode still crashes.
>
> There was a recent change that might be related I first tried to  
> install MacRuby in a non-system dir. See: http://ruby.macosforge.org/trac/ticket/71
>
> I did not use the program prefix, this was my configure line:
>
> ./configure --enable-framework --enable-fat-binary --prefix=/Users/ 
> stephen/dev/MacRuby/macruby
>
> The binaries were installed into /usr/local/bin instead of /Users/ 
> stephen/dev/MacRuby/macruby.
>
> I ended up archiving all the newly generated binaries in /usr/local/ 
> bin and re-running the install as your documentation recommends.
>
> Do you think interactions between the earlier problematic and then  
> later installs might have caused a problem?
>
> I like to be able to install alternative Ruby VMs in non-system  
> directories. I have ruby1.9, jruby, and rubinius installed this way.  
> Part of the reason is so I don't have to worry about renaming ruby  
> bin/ commands like rake or gem. Another part of the reason is so  
> that I have a single dir where all the installed artifacts for a  
> ruby vm live which makes it easier to see all the parts. Another  
> reason is that it makes it easy to delete all the build products and  
> start over.
>
> It could be that my attempt to install macruby in a non-system dir  
> ended up causing the type of problem I was hoping to avoid ...!
>
> How can I remove all the macruby artifacts installed by the first  
> and then subsequent 'sudo make install' commands so I can start over?

I don't think your previous attempt is causing this problem. If you  
want to to start over, you can just check out a fresh copy of trunk,  
and build/install it as described in the wiki.

Just wondering, regarding your environment, do you have a little  
amount of memory available at the time you start CircleView? Or, is  
there a process that uses most of the memory at the same time?

Laurent


More information about the MacRuby-devel mailing list