Satoshi Nakagawa
snaka****@infot*****
Wed Jan 9 07:20:18 JST 2008
Hi, As I committed in r2164 and r2165, I fixed a problem related to the ruby GC. I received some crash reports from LimeChat users, many of them indicated LimeChat accessed to an address already deallocated. Thread 0 Crashed: 0 libSystem.B.dylib 0x942c247a __kill + 10 1 libSystem.B.dylib 0x94339782 raise + 26 2 libSystem.B.dylib 0x94348d3f abort + 73 3 libruby.1.dylib 0x000cdc50 rb_exc_new + 0 4 libruby.1.dylib 0x0013464f rb_gc_mark_trap_list + 508 5 libSystem.B.dylib 0x942c097b _sigtramp + 43 6 ??? 0xffffffff 0 + 4294967295 7 libobjc.A.dylib 0x910c56b0 look_up_method + 106 8 com.apple.rubycocoa 0x0002c651 objcptr_cptr + 1505 9 com.apple.rubycocoa 0x0002d9a6 objcptr_cptr + 6454 Then accidentally, it seemed I found a cause of the problem. I read Ruby Hacking Guide. http://i.loveruby.net/ja/rhg/book/gc.html (in Japanese) Translated as below: ---- * Take care of GC using volatile As I wrote GC takes care of VALUEs on the stack. Therefore if I put a VALUE as a local variable, the VALUE should be marked surely. But in fact some kind of optimizations could erase local variables. For example: VALUE str; str = rb_str_new2("..."); printf("%s\n", RSTRING(str)->ptr); There are no accesses to 'str' itself, so some compilers could erase 'str' sometimes while retaining 'str->ptr'. Then 'str' can be collected by GC. A solution for this problem is to use volatile. ---- It's applicable for some code in rubycocoa. I fixed some parts as far as I can recognize. The important point is to make sure all VALUEs held in local variables should be pushed on the stack. I don't know much about libffi. Laurent, could you investigate around libffi calls? -- Satoshi Nakagawa
