[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