RubyCocoaのLionでの問題を修正 - (1) - きりかノート 3冊め

Lionでruby install.rb setupが失敗する
NSDataからバイト列を取り出すと落ちる

ChangeLogを見るに、なんとほぼ2年ぶりのコミット。いろいろすみません、、、

Lionでruby install.rb setupが失敗する

原因は`xcodebuild -version'の出力が変わったこと。新しい形式に合わせて調整してもいいんだけど、LionでXcode 2.x以下のバージョン使うとも思えないのでシステムのバージョンを利用して10.7以上はXcode4以上だろうと判断するようにした（r2304）。

NSDataからバイト列を取り出すと落ちる

なんだかNSDataからバイト列を取り出すと落ちるぽい。MLのほうに報告されてたのも同じ問題のよう。

問題の動きとしては、-[NSData bytes]で得られるバイト列のデータはRubyCocoa的にはOSX::ObjcPtrクラスになるはずなんだけど、なぜか__NSCFStringになったりしてもちろん落ちてしまう。最近いじってなかったので思い出せないことがたくさん。$DEBUG = trueを仕込んで動作確認しながらコード追ってみたり。

その結果、ocdata_to_rbobj()の

 octype_str = encoding_skip_qualifiers(octype_str);

 bs_boxed = find_bs_boxed_by_encoding(octype_str);
 if (bs_boxed != NULL) {
   *result = rb_bs_boxed_new_from_ocdata(bs_boxed, (void *)ocdata);
   return YES;
 }

 if (find_bs_cf_type_by_encoding(octype_str) != NULL)
   octype_str = "@";

の最後のところで、型エンコーディングが"^v"（つまり*void）のときも真の方を通ってしまっていることがわかった。find_bs_cf_type_by_encoding()は何かっていうと、bridgesupportから生成した型エンコーディングと型名のst_table表から登録された型名を探索するってもので、これが*voidを渡したときに見つかるのはだめだろうと。

このへんでだいぶつかれたので、とりあえずの措置としてfind_bs_cf_type_by_encoding()に"^v"が渡されたときは問答無用でNULLを返すようにした（r2306）。

型情報のテーブルのところを調べて、実際に'^v'のデータが.bridgesupportファイルからエントリされる（たとえばCoreFoundationのCFTypeRef）ことがわかった。今のまま探索時にチェックする方法の他に、テーブルの登録時で除外するという手もある。考えた結果、エンコーディングからの検索にしか使えないのでそもそも登録する意味がないので登録時に外すようにした（r2307）。もうひとつのCFTypeIDからの検索は別のテーブル使ってるし。

ということでこの問題はたぶん完了。

今後の予定

まだLion上でテストを通らないところがあるのでひきつづき調査中。これまで時間とれなかったことが多かったのだけどしばらく余裕ありそうなので、今月のうちには目処をつけてひさしぶりのリリースをしたいと思います。