び:log-2005
一応解決
(2005/11/24 15:19:21 PST): Gauche:Bugsにも書いたけど、Mac OS X や NetBSD 2.1.0_STABLEでSEGVが起きる問題は個人的にはほぼ解決した。問題の焦点は2つ。
- read-blockで渡されたブロック長いっぱいの不完全文字列を読み込んだとき、今の文字列の考え方だとブロック長+1の領域を確保しなければいけないのにブロック長きっちりしか確保していない。
- get_string_from_body()が渡されたScmStringBody *bのSCM_STRING_BODY_START(b)[size]が'\0'であるかどうかで、バッファそのものを返すか、バッファのコピーを返すかを判断している。
スジ的に考えると後者はちょっと怪しい(だって不完全文字列って文字列中に\0含む可能性あるし)。が、効率を考えると前者に手を入れた方がいい。そもそも、Shiroさんも言っているように、完全文字列と不完全文字列との扱いはいまひとつ未整理という感じがあるし、そこを明確にしないと、後者だけうだうだ言っても始まらない。
- Shiro(2005/11/25 15:24:36 PST): ありがとうございます。
文字列途中の \0 は、完全/不完全文字列とは直交する問題でして、
完全文字列であっても途中に \0 を含む可能性はあります。
これはもう、ASCIZ文字列を期待するC APIに文字列を渡す場合に
caller側が気をつけるしかない問題です。Scm_GetStringConst()は
Scheme文字列からASCIZ文字列を取り出すAPIなので、渡されるScheme文字列中に
\0が含まれないことはアプリ側で保証していると考えます。
その上で、余分なcopyを避けるために文字列本体の実体の後に\0が来ていれば
本体への参照をそのまま返す、ということをやっています。
文字列が完全であっても不完全であってもこの部分は変わりません。
- (2005/11/25 17:50:29 PST): なるほど。わたしはかなり意図を取り違えていた(というよりある種の思い込みにとらわれていた)みたいです。
今度はNetBSD 2.1.0_STABLE
(2005/11/10 05:21:25 PST): Mac OS Xではすっかり問題なくなったように見えていたのだが、何とNetBSD 2.1.0_STABLE上でCVS HEADをビルドし、sudo make install && make install-checkしたらSEGVで落ちやがった。coreを覗くと、何とまぁMac OS Xの時と全く同じ場所で落ちてる。ううむむむ... こりゃやっぱり何かあるな。
Mac OS X 10.4.3(8F46)続々々(Final)
CVS HEADが0.8.6になったのを見てビルドしてみたら、何とすんなりmake install-checkが通ってしまった。どういうこっちゃ。昨日までは確かに通らなかったのに... ということで、原因究明できぬまま自然解決してしまった。いいのかそれで...
Mac OS X 10.4.3(8F46)続々
腰を据えてコードを追う暇はないんだけど、気になるから合間についつい実験してしまう。 試したのは'CFLAGS=-g -O2'でビルドした本体に'CFLAGS=-g -O'でビルドしたlibcharconv.so、あるいはその逆という組み合わせ実験。結果は
- | Gauche(-O2) | Gauche(-O) |
libcharconv.so(-O2) | × | ○ |
libcharconv.so(-O) | × | ○ |
ということで、たぶんldの再配置問題は関係なさそうな気配。何となく最適化レベルとの関係と落ちているのが文字列の操作の中であることから、アライメント問題か? という気がする。続きは夜にでも。
- skimu(2005/11/01 21:07:01 PST): さっき cvs update かけて作ってみましたが正常でした。(G5 dual 1.8G, 8F46) コンパイラは powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026) 。gcc3 や gcc2 でやるとどうなるかちょっと気になります。あと、libgauche をスタティックリンクしてみるとか。
- び(2005/11/02 03:55:14 PST): ありがとうございます。うちでも古いPowerBook G4では問題が発生しないので、個体の問題か、構成の問題のような気がしてきています。ちなみにgcc4のバージョンはskimuさんと同じです。
- Shiro(2005/11/02 04:00:56 PST): こちらでも10.8.3の環境を用意して試してみました
(Mac mini)が、問題は再現できませんでした。コンパイラはskimuさんのと同じ。
気にはなりますが、どうにか他の問題は片付いてきたんで、一旦0.8.6を出すことにします。
- び(2005/11/02 05:11:23 PST): はい。お騒がせしました。とりあえず正常に動作するマシンとダメなマシンとの間で比較をしてみることにします。
Mac OS X 10.4.3(8F46)続
(2005/11/01 14:47:29 PST): そういえばと思い出してCrashReporterのログを眺めてみた。
Host Name: albatross Date/Time: 2005-11-02 07:39:38.633 +0900 OS Version: 10.4.3 (Build 8F46) Report Version: 3 Command: gosh Path: /usr/local/bin/gosh Parent: zsh [744] Version: ??? (???) PID: 928 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x00793000 Thread 0 Crashed: 0 libgauche.dylib 0x00220f0c get_string_from_body + 28 (string.c:244) 1 libgauche.dylib 0x00228cb8 Scm_PutsUnsafe + 120 (portapi.c:203) 2 libgauche.dylib 0x00228dfc Scm_Puts + 84 (portapi.c:195) 3 libgauche.dylib 0x00224788 string_print + 56 (string.c:1195) 4 libgauche.dylib 0x002310ac write_ss_rec + 1592 (write.c:538) 5 libgauche.dylib 0x00231510 Scm_Write + 872 (write.c:164) 6 libgauche.dylib 0x00258bf0 stdlib_display + 216 (stdlib.c:3943) 7 libgauche.dylib 0x00208f38 run_loop + 1196 (vm.c:885) 8 libgauche.dylib 0x002111a0 user_eval_inner + 564 (vm.c:2870) 9 libgauche.dylib 0x0024b27c Scm_Load + 164 (load.c:430) 10 gosh 0x000038a0 main + 1700 (main.c:408) 11 gosh 0x00002364 _start + 344 (crt.c:272) 12 gosh 0x00002208 start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x0000000000220f0c srr1: 0x000000000200f930 vrsave: 0x0000000000000000 cr: 0x22002242 xer: 0x0000000000000004 lr: 0x0000000000228cb8 ctr: 0x0000000000220f6c r0: 0x0000000000228cb8 r1: 0x00000000bfffe8a0 r2: 0x000000000062d558 r3: 0x0000000000792f00 r4: 0x00000000bfffe928 r5: 0x0000000000000000 r6: 0x0000000000000000 r7: 0x00000000000000ff r8: 0x00000000bfffeeb4 r9: 0x00000000002b013b r10: 0x0000000000206a20 r11: 0x00000000002e362c r12: 0x0000000000220f6c r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0x0000000000298a94 r21: 0x00000000002e8a94 r22: 0x0000000000298a94 r23: 0x0000000000298a94 r24: 0x00000000002b087f r25: 0x00000000a0001b98 r26: 0x0000000000757a10 r27: 0x0000000000000000 r28: 0x000000000062d560 r29: 0x000000000062d558 r30: 0x0000000000000100 r31: 0x0000000000228c4c Binary Images Description: 0x1000 - 0x4fff gosh /usr/local/bin/gosh 0xd4000 - 0xd7fff srfi-1-lib.so /usr/local/lib/gauche/0.8.6_pre3/powerpc-apple-darwin8/srfi-1-lib.so 0x205000 - 0x2abfff libgauche.dylib /usr/local/lib/libgauche.dylib 0x4c6000 - 0x4cafff srfi-13-lib.so /usr/local/lib/gauche/0.8.6_pre3/powerpc-apple-darwin8/srfi-13-lib.so 0x706000 - 0x70bfff libcharconv.so /usr/local/lib/gauche/0.8.6_pre3/powerpc-apple-darwin8/libcharconv.so 0x8fe00000 - 0x8fe54fff dyld 44.2 /usr/lib/dyld 0x90000000 - 0x901b3fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x9020b000 - 0x90210fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x913ad000 - 0x913b5fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib 0x913ba000 - 0x913dbfff libmx.A.dylib /usr/lib/libmx.A.dylib 0x92cea000 - 0x92dd8fff libiconv.2.dylib /usr/lib/libiconv.2.dylib
Gauche:MTと文字列で加えられた変更と何か関係があるのかな...
Mac OS X 10.4.3(8F46)
今朝10.4.3がリリースされたので、新しいPB17でアップデートをかけて再びデフォルトのCFLAGS(-g -O2)でビルドしてみた。全く同じ症状でSEGVを喰らう。'CFLAGS=-g -O'を./configureに渡して再ビルドするとOK。帰ったら古いPowerBookでも試してみよう。
(2005/11/01 13:28:44 PST追記): 古いPowerBook G4を10.4.3にアップデートしてGaucheをビルドし直してみたが、SEGVは喰らわないで普通にmake install-checkが通ってしまう。今度はMac OS Xのビルドナンバーは新しいPowerBook G4のものと同じ。どうなってるんだ??
- Shiro(2005/10/31 23:21:35 PST): 問題の出るビルドで *.so 中のdataと
bssの配置を調べてみて下さい:
nm libcharconv.so | grep ' [bB] ' nm libcharconv.so | grep ' [dD] '
意図として、Scm__data{start|end}_charconvとScm__bss{start|end}_charconv というシンボルがそれぞれdata領域とbss領域の変数を挟んでいて欲しいのですが、 ldが変数の再配置を行うために意図通りにならないシステムがあります。 data領域に関してはBoehm GC側にも検出コードがあるのですが、bss領域は Scm__bss{start|end}_charconvの外側にある変数がgcから保護されません。
- び(2005/11/01 05:25:07 PST): 調べてみました。
;;; 'CFLAGS=-g -O'を渡してビルドした「SEGVしない版」 % nm libcharconv.so|grep ' [bBdDsS] '|sort -t ' ' -k 1 00005f78 s ___PRETTY_FUNCTION__.7871 00005ff0 s ___PRETTY_FUNCTION__.8140 00006038 s _C.53.5811 00007000 d dyld__mh_bundle_header 00007004 D _Scm__datastart_charconv 00007008 d _convlib_ces_conversion_supportedP__NAME 00007020 d _convlib_ces_conversion_supportedP__STUB 00007040 d _KEYARG_to_code__NAME 00007058 d _KEYARG_to_code 0000705c d _KEYARG_buffer_size__NAME 00007074 d _KEYARG_buffer_size 00007078 d _KEYARG_ownerP__NAME 00007090 d _KEYARG_ownerP 00007094 d _KEYARG_handler__NAME 000070ac d _KEYARG_handler 000070b0 d _convlib_open_input_conversion_port__NAME 000070c8 d _convlib_open_input_conversion_port__STUB 000070e8 d _KEYARG_from_code__NAME 00007100 d _KEYARG_from_code 00007104 d _convlib_open_output_conversion_port__NAME 0000711c d _convlib_open_output_conversion_port__STUB 0000713c d _convlib_ces_guess_from_string__NAME 00007154 d _convlib_ces_guess_from_string__STUB 00007174 d _scm__rc 00008760 d _toplevels 00008768 d _cvt.5645 00008772 d _utf2euc_c2 000087f2 d _utf2euc_c3 00008872 d _utf2euc_c4 000088f2 d _utf2euc_c5 00008972 d _utf2euc_c7 000089f2 d _utf2euc_c9 00008a72 d _utf2euc_ca 00008af2 d _utf2euc_cb 00008b72 d _utf2euc_cc 00008bf2 d _utf2euc_ce 00008c72 d _utf2euc_cf 00008cf2 d _utf2euc_d0 00008d72 d _utf2euc_d1 00008df4 d _utf2euc_e2 00008e34 d _utf2euc_e2_xx 00009c34 d _utf2euc_e3 00009c74 d _utf2euc_e3_xx 0000b5f4 d _utf2euc_e4 0000b634 d _utf2euc_e4_xx 0000ce34 d _utf2euc_e5 0000ce74 d _utf2euc_e5_xx 0000ee74 d _utf2euc_e6 0000eeb4 d _utf2euc_e6_xx 00010eb4 d _utf2euc_e7 00010ef4 d _utf2euc_e7_xx 00012e74 d _utf2euc_e8 00012eb4 d _utf2euc_e8_xx 00014e34 d _utf2euc_e9 00014e74 d _utf2euc_e9_xx 00016c74 d _utf2euc_ef 00016cb4 d _utf2euc_ef_xx 00017134 d _utf2euc_f0_a0 000171a8 d _utf2euc_f0_a1 0001723c d _utf2euc_f0_a2 00017280 d _utf2euc_f0_a3 00017330 d _utf2euc_f0_a4 0001737c d _utf2euc_f0_a5 00017414 d _utf2euc_f0_a6 00017490 d _utf2euc_f0_a7 000174f8 d _utf2euc_f0_a8 00017598 d _utf2euc_f0_a9 000175e8 d _utf2euc_f0_aa 00017618 d _euc_jisx0201_to_ucs2 00017698 d _euc_jisx0213_1_to_ucs2 000200a8 d _euc_jisx0213_2_index 00020164 d _euc_jisx0213_2_to_ucs2 00022794 d _conv_converter 000227d0 d _conv_supports 00022878 d _guess_eucj_st 00022c78 d _guess_eucj_ar 00022ccc d _guess_sjis_st 00022ecc d _guess_sjis_ar 00022f14 d _guess_utf8_st 00023514 d _guess_utf8_ar 00023598 D _Scm__dataend_charconv 0002359c s dyld_lazy_symbol_binding_entry_point 000235a0 s dyld_func_lookup_pointer 00023684 s _scm__sc 00023f84 s _C.14.5534 00023f98 s _C.13.5533 00023fac s _C.12.5532 00023fc0 S _Scm__bssstart_charconv 00023fc4 S _Scm__bssend_charconv 00023fc8 b _guess 00023ff8 b _ucsconv ;;; 'CFLAGS=-g -O2'を渡してビルドした「SEGV喰らう版」 % nm libcharconv.so|grep ' [bBdDsS] ' |sort -t ' ' -k 1 00005f18 s ___PRETTY_FUNCTION__.6372 00005f90 s ___PRETTY_FUNCTION__.6502 00005fd8 s _C.28.5720 00006000 d dyld__mh_bundle_header 00006004 D _Scm__datastart_charconv 00006008 d _convlib_ces_conversion_supportedP__STUB 00006028 d _convlib_ces_conversion_supportedP__NAME 00006040 d _convlib_open_input_conversion_port__STUB 00006060 d _convlib_open_input_conversion_port__NAME 00006078 d _KEYARG_to_code 0000607c d _KEYARG_to_code__NAME 00006094 d _KEYARG_buffer_size 00006098 d _KEYARG_buffer_size__NAME 000060b0 d _KEYARG_ownerP 000060b4 d _KEYARG_ownerP__NAME 000060cc d _KEYARG_handler 000060d0 d _KEYARG_handler__NAME 000060e8 d _convlib_open_output_conversion_port__STUB 00006108 d _convlib_open_output_conversion_port__NAME 00006120 d _KEYARG_from_code 00006124 d _KEYARG_from_code__NAME 0000613c d _convlib_ces_guess_from_string__STUB 0000615c d _convlib_ces_guess_from_string__NAME 00006174 d _toplevels 0000617c d _scm__rc 00007768 d _conv_converter 000077a4 d _euc_jisx0213_1_to_ucs2 000101b4 d _euc_jisx0213_2_to_ucs2 000127e4 d _euc_jisx0213_2_index 000128a0 d _utf2euc_d1 00012920 d _utf2euc_d0 000129a0 d _utf2euc_cf 00012a20 d _utf2euc_ce 00012aa0 d _utf2euc_cc 00012b20 d _utf2euc_cb 00012ba0 d _utf2euc_ca 00012c20 d _utf2euc_c9 00012ca0 d _utf2euc_c7 00012d20 d _utf2euc_c5 00012da0 d _utf2euc_c4 00012e20 d _utf2euc_c3 00012ea0 d _utf2euc_c2 00012f20 d _utf2euc_ef_xx 000133a0 d _utf2euc_ef 000133e0 d _utf2euc_e9_xx 000151e0 d _utf2euc_e9 00015220 d _utf2euc_e8_xx 000171a0 d _utf2euc_e8 000171e0 d _utf2euc_e7_xx 00019160 d _utf2euc_e7 000191a0 d _utf2euc_e6_xx 0001b1a0 d _utf2euc_e6 0001b1e0 d _utf2euc_e5_xx 0001d1e0 d _utf2euc_e5 0001d220 d _utf2euc_e4_xx 0001ea20 d _utf2euc_e4 0001ea60 d _utf2euc_e3_xx 000203e0 d _utf2euc_e3 00020420 d _utf2euc_e2_xx 00021220 d _utf2euc_e2 00021260 d _utf2euc_f0_aa 00021290 d _utf2euc_f0_a9 000212e0 d _utf2euc_f0_a8 00021380 d _utf2euc_f0_a7 000213e8 d _utf2euc_f0_a6 00021464 d _utf2euc_f0_a5 000214fc d _utf2euc_f0_a4 00021548 d _utf2euc_f0_a3 000215f8 d _utf2euc_f0_a2 0002163c d _utf2euc_f0_a1 000216d0 d _utf2euc_f0_a0 00021744 d _conv_supports 000217ec d _cvt.5645 000217f8 d _guess_utf8_ar 0002187c d _guess_utf8_st 00021e7c d _guess_sjis_ar 00021ec4 d _guess_sjis_st 000220c4 d _guess_eucj_ar 00022118 d _guess_eucj_st 00022518 D _Scm__dataend_charconv 0002251c s dyld_lazy_symbol_binding_entry_point 00022520 s dyld_func_lookup_pointer 00022604 s _scm__sc 00022f04 s _C.14.5534 00022f18 s _C.13.5533 00022f2c s _C.12.5532 00022f40 S _Scm__bssstart_charconv 00022f44 S _Scm__bssend_charconv 00022f48 b _ucsconv 00022f7c b _guess
たぶん違う問題じゃないかなぁ、と思う。ちなみに問題の起きていないNetBSD-3.0BETA/i386で同じことをしてみた('CFLAGS=-g -O2')。% nm libcharconv.so |grep ' [bBdD] '|sort -t ' ' -k1 000084c0 d __dso_handle 000084c4 d p.0 000084c8 D Scm__datastart_charconv 000084cc d KEYARG_to_code 000084d0 d KEYARG_buffer_size 000084d4 d KEYARG_ownerP 000084d8 d KEYARG_handler 000084dc d KEYARG_from_code 000084e0 d convlib_ces_conversion_supportedP__NAME 00008500 d convlib_ces_conversion_supportedP__STUB 00008520 d KEYARG_to_code__NAME 00008538 d KEYARG_buffer_size__NAME 00008550 d KEYARG_ownerP__NAME 00008568 d KEYARG_handler__NAME 00008580 d convlib_open_input_conversion_port__NAME 000085a0 d convlib_open_input_conversion_port__STUB 000085c0 d KEYARG_from_code__NAME 000085d8 d convlib_open_output_conversion_port__NAME 00008600 d convlib_open_output_conversion_port__STUB 00008620 d convlib_ces_guess_from_string__NAME 00008640 d convlib_ces_guess_from_string__STUB 00008660 d scm__sc 00008f60 d scm__rc 0000a54c d toplevels 0000a560 d cvt.0 0000a580 d utf2euc_c2 0000a600 d utf2euc_c3 0000a680 d utf2euc_c4 0000a700 d utf2euc_c5 0000a780 d utf2euc_c7 0000a800 d utf2euc_c9 0000a880 d utf2euc_ca 0000a900 d utf2euc_cb 0000a980 d utf2euc_cc 0000aa00 d utf2euc_ce 0000aa80 d utf2euc_cf 0000ab00 d utf2euc_d0 0000ab80 d utf2euc_d1 0000ac00 d utf2euc_e2 0000ac40 d utf2euc_e2_xx 0000ba40 d utf2euc_e3 0000ba80 d utf2euc_e3_xx 0000d400 d utf2euc_e4 0000d440 d utf2euc_e4_xx 0000ec40 d utf2euc_e5 0000ec80 d utf2euc_e5_xx 00010c80 d utf2euc_e6 00010cc0 d utf2euc_e6_xx 00012cc0 d utf2euc_e7 00012d00 d utf2euc_e7_xx 00014c80 d utf2euc_e8 00014cc0 d utf2euc_e8_xx 00016c40 d utf2euc_e9 00016c80 d utf2euc_e9_xx 00018a80 d utf2euc_ef 00018ac0 d utf2euc_ef_xx 00018f40 d utf2euc_f0_a0 00018fc0 d utf2euc_f0_a1 00019060 d utf2euc_f0_a2 000190c0 d utf2euc_f0_a3 00019180 d utf2euc_f0_a4 000191e0 d utf2euc_f0_a5 00019280 d utf2euc_f0_a6 00019300 d utf2euc_f0_a7 00019380 d utf2euc_f0_a8 00019420 d utf2euc_f0_a9 00019480 d utf2euc_f0_aa 000194c0 d euc_jisx0201_to_ucs2 00019540 d euc_jisx0213_1_to_ucs2 00021f60 d euc_jisx0213_2_index 00022020 d euc_jisx0213_2_to_ucs2 00024660 d conv_converter 000246a0 d conv_supports 00024760 d guess_eucj_st 00024b60 d guess_eucj_ar 00024bc0 d guess_sjis_st 00024dc0 d guess_sjis_ar 00024e20 d guess_utf8_st 00025420 d guess_utf8_ar 000254e0 D Scm__dataend_charconv 000255a8 d __CTOR_LIST__ 000255ac d __CTOR_END__ 000255b0 d __DTOR_LIST__ 000255b4 d __DTOR_END__ 000255b8 d __JCR_END__ 000255b8 d __JCR_LIST__ 00025700 b completed.1 00025704 b object.2 00025720 b guess 00025740 b ucsconv 00025764 B Scm__bssstart_charconv 00025768 B Scm__bssend_charconv
New PowerBook G4 17"
ふと思い立って、configureにCFLAGS="-g -O"を渡して再ビルドしてみると、SEGV喰らわずにmake install-checkをクリアする。ますます微妙なところを踏んでいる気配。
New PowerBook G4 17"
2005/10/28 19:38:00 PDT: 新しいPowerBook 17インチが届いたので、「うひょひょ、画面が広いー」といい気になっていたのだが、CVS HEADのGaucheをビルド/インストールしてみたら、make install-check中charconvのテストでSegmentation Faultを起こす。make check中は起こさない。古いPowerBook 17インチではこの問題は発生せず、make check/make install-checkともに正常終了する。どちらもソフトウェアアップデートで最新にしてある。何が違うんじゃーとあれこれみて回ったら、
[新しいPowerBook] % sw_vers ProductName: Mac OS X ProductVersion: 10.4.2 BuildVersion: 8E45 [古いPowerBook] % sw_vers ProductName: Mac OS X ProductVersion: 10.4.2 BuildVersion: 8C46
ビルドナンバーが違うでやんの。とりあえずcoreを採取してgdbで覗いてみると...
% gdb /usr/local/bin/gosh /cores/core.4744 GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .... done #0 0x0022102c in GC_explicit_kind () (gdb) where #0 0x0022102c in GC_explicit_kind () #1 0x00228dd8 in GC_explicit_kind () warning: Previous frame identical to this frame (corrupt stack?) #2 0x00228dd8 in GC_explicit_kind () #3 0x00228f1c in GC_explicit_kind () #4 0x002248a8 in GC_explicit_kind () #5 0x002311cc in GC_explicit_kind () #6 0x00231630 in GC_explicit_kind () #7 0x00258d10 in GC_explicit_kind () #8 0x00209058 in GC_explicit_kind () #9 0x002112c0 in GC_explicit_kind () #10 0x0024b39c in GC_explicit_kind () #11 0x000038a0 in Scm_VMApply2 (proc=0x0, arg1=0x62d570, arg2=0x62d578) at vm.c:2748 (gdb)
GCまわりの問題らしい。ううむ... しかもさらに奇妙なことに、
% cd ext/charconv % make install-check : [中略] passed. % make install-check >/dev/null Testing charconv ... make: *** [install-check] Segmentation fault (core dumped)
... 何のこっちゃ。わけがわからない。
- Shiro(2005/10/29 20:11:11 PDT): 一度CVS HEADがinstallされてる状態でもういちどmake distcleanからやると、install-check通ったりしません?
私のところ(Linux 2.6.13, gcc 4.0.1) でもこれでひっかかってます。
- び(2005/10/29 21:43:52 PDT): 一応毎回make maintainer-cleanしてから作っています。念のためもう一度やってみましたが、結果は同じでした。面白いのは、ext/charconv/test.scmの97行目の前に
(test-section "fixed conversion jp3")
を挿入するとpassするってことです。100行目の前に挿入しても落ちます。ということで、どこか微妙な所を踏んでいるような気がしています。今夜時間を作ってもう少し追ってみます。
- び(2005/10/29 21:43:52 PDT): 一応毎回make maintainer-cleanしてから作っています。念のためもう一度やってみましたが、結果は同じでした。面白いのは、ext/charconv/test.scmの97行目の前に
Reasoned Schemer届いた
夜帰宅したら届いていた。前2冊よりも薄いから持ち運びに便利(そんなに差があるわけじゃないが)。ここんとこ忙しいから、出張のお供にでもするか。
Reasoned Schemerその後
まだ来ねぇ。Amazonの出荷予定は10/14-16のまま。せめて過ぎちまったら「未定」に変えるとかすりゃいいのに。出版が遅れてるのかねぇ...
util.match 初体験
何だかよくわかっていなかったので今まで手を出さずにいたutil.matchを使ってみた。これめちゃめちゃ強力。入り組んだS式を解析したりいじったりがとても簡単になる。その昔はじめてsedやawk、perlの正規表現に触れたときの「何でも正規表現でできちゃいそうな気分」を思い出した。何でもS式でやれちゃう病発症かしら(笑)。
Boehm-gc on NetBSDその後
Hansから予想通りGC_restart_world()を同期的にしたことについてツッコミ。
- これってこの問題とは違うの?
- で、6.6でもこのコードは本当に必要?
- 必要だとしたらこれって本当にNetBSD-specific?
- もしNetBSD-specificならその旨コメントが必要だし、そうじゃないんだったら潜在的な問題として扱うべきだと思う。
どれもこれも至極もっともな話。でそれに対する返答。
- たぶん違うと思うよ。NetBSDでは、時々SIG_SUSPENDが投げられてるのにsuspend_handler()が呼ばれないことがあって、そのせいでGC_stop_world()のsem_wait()が永久にsem_post()を待ち続けてしまうんだ。
- 6.6でも必要。
- たぶんNetBSD-specificじゃない。少なくともGC_stop_world()が同期的に働くなら、GC_restart_world()も同じように働くべき。だけど、当然オーバーヘッドがあるから、他のプラットフォームで同様の問題が発生しないなら、NetBSD-specificなコードということにした方がいいのかもしれない。
俺の壊れた英語じゃあどこまで伝わったか不明。つーか、俺がNetBSDで発生するSIG_SUSPENDのロストを現象面でしか理解してないのが一番の問題だな。でも、正直なんでロストするのかわからなかったんだもの。
SLIME de Scheme48
Emacs上のCommon Lisp統合環境として最近よく話題に上るSLIMEをScheme48に対しても使えるようにしたSLIME48ってのがあるらしい。実は「SLIMEはすごいらしい」という噂話を聞いて、「それってGaucheでも使えるようにならんかな」と思いソースを覗き始めたところだったので、先を越された気分。まぁ俺の場合「思いつくだけ」でなかなか行動に移らないのだけれど。
化けるかな
ということで?が?になっちゃう問題検証のためにOpera 8.50 on Mac OS Xで書き込み。大丈夫っぽいね。
The Reasoned Scheme
もうすぐ出ると言う話を聞いてAmazonで予約。SICPが重かった頃(いや、今でも重いのだけれど)、The Little SchemerとThe Seasoned Schemerはよく読んだ。著者が一部替わってるみたいだけど、前2作のように「軽く読めて、時々はっとさせられる」好著だといいな。
- これ見て私も早速注文。今回はOlegさんが著者に名を連ねているんですよね。 マクロとか出て来ないかなぁ。cut-sea:2005/09/19 17:51:46 PDT
R5RS Pitfalls Test
というものがあるのを知った。R5RS Pitfalls Test Resultsを見ると、Gaucheのバージョンが結構古い。今のCVS HEADだとどうなんだろ、と思い試してみた。
% gosh ~/Desktop/r5rs_pitfall.scm Failure: 1.1, expected '0', got '1'. Failure: 1.2, expected '#t', got '#f'. Passed: 1.3 Passed: 2.1 Passed: 3.1 Passed: 3.2 Failure: 3.3, expected '1', got '2'. *** ERROR: Compile Error: malformed macro x: (syntax-rules ()) "/Users/bizenn/Desktop/r5rs_pitfall.scm":114:(should-be 3.4 1 (let-syntax ((x (sy ... Stack Trace: _______________________________________ %
ありゃりゃ。r5rs_pitfall.scmの覗いてみると、3.4でひっかかってるようだ。仕方ないのでこのテストだけ コメントアウトして再実行
% gosh ~/Desktop/r5rs_pitfall.scm Failure: 1.1, expected '0', got '1'. Failure: 1.2, expected '#t', got '#f'. Passed: 1.3 Passed: 2.1 Passed: 3.1 Passed: 3.2 Failure: 3.3, expected '1', got '2'. Passed: 4.1 Passed: 4.2 Passed: 4.3 Passed: 5.1 Passed: 5.2 Passed: 5.3 Passed: 6.1 Passed: 7.1 Passed: 7.2 Passed: 7.3 Passed: 7.4 Passed: 8.1 Passed: 8.2 Passed: 8.3 Map is not call/cc safe, but probably tail recursive and efficient. %
ふむ。7.4は通るようになったんだね。通らないのは1.1、1.2、3.3、3.4かぁ。1.1と1.2は何となくScheme:call/ccパズルの話に似ているような。3.3と3.4はマクロコンパイラの話だね。そしてmapはcall/cc safeじゃないぞ、と。ちなみにsiscの最新版1.11.3はどうかというと、
% sisc -x ~/Desktop/r5rs_pitfall.scm Passed: 1.1 Passed: 1.2 Passed: 1.3 {warning: compiler detected application of non-procedure '0'.) Passed: 2.1 Passed: 3.1 Passed: 3.2 Passed: 3.3 Passed: 3.4 Passed: 4.1 Passed: 4.2 Passed: 4.3 Passed: 5.1 Passed: 5.2 Passed: 5.3 Passed: 6.1 Passed: 7.1 Passed: 7.2 Passed: 7.3 Passed: 7.4 Passed: 8.1 Passed: 8.2 Failure: 8.3, expected '1', got '2'. Map is call/cc safe, but probably not tail recursive or inefficient. %
なかなかパーフェクトとはいかないようで。何にせよ、自分が使う実装の弱点を知っとくのも大事。
あーりゃりゃ、boehm-gc 6.6出ちゃったよ... lwpを使う方法はうまくいってないし、そろそろ諦めて現状のパッチを投げた方がいいかなぁ...
メーリングリストにパッチ投げちゃいました。さて、マージしてもらえるかな...
cut-seaさんのところのプリティプリンタの話に刺激されて、ちょうどデータとしてのS式を整形したいと思ってたこともあって、10分クッキングででっち上げてみた。イマイチ。もっとスマートにできないものか?
- び (2005/09/10 07:37:19 PDT): コードも移動しました→Gauche:PrettyPrint
RtS:Shiroを読んで、Lisp体験のスタートがまんま同じだということを知ってびっくり。その後も経緯もけっこう似ている。にもかかわらずこの彼我の差は何。
Kahuaでファイルアップロード(2005/08/16 01:47:41 PDT)
Shiro: 一般的な話題なのでGauche:www.cgiとファイルアップロードに 移動しました。