#勝手に_XPG4_2を定義しちゃまずいみたいですね。#define _XOPEN_SOURCE #define _XOPEN_SOURCE_EXTENDED 1を定義しとけばいいのかな (http://docs.sun.com/app/docs/doc/819-2252/standards-5?a=view) ライブラリについてはマクロでsendmsg関数自体を切り替えてるみたいですね。 #試しに、src/gauche/config.hに上のふたつの#defineを定義してmake clean; makeしてみたらどうなりますか。
#ついでに、gauche-config --archの結果も教えてください。上の#defineで解決するなら、configure.acの方でOpenSolarisの場合に定義を追加するようにします。
#まず、_XOPEN_SOURCEと_XOPEN_SOURCE_EXTENDED=1で定義しましたが、feature_tests.hの352行で引っ掛かってエラーになりました。XPG5以前はC99としてコンパイルできないみたいです。
#次に、#define _XOPEN_SOURCE 600で定義して再度makeしたところ、u_longが未定義でエラーになりました。/usr/include/sys/types.hを確認したところ、XPGやPOSIX互換だと、u_longなどの定義は、ばっさりカットされてしまうようです。
#$ gauche-config --arch
i386-pc-solaris2.11
#gauche-config --archは上記のようになりました。
#>> shiroさん。tarballというのは、0.9_rc1のtarballでしょうか？ sourceforge.netを探したのですが、どこからダウンロードするのか見つかりませんでした…。
#メーリングリスト(gauche-devel)にURLが流れてました
##これのことだと思います
#お、ありがとうございます。試してみます。
#tarballだとコンパイルが通りました。
#make checkでthreadsのテストがなかなか終わらないです。
#刺さってるとか?
#かもしれないですね。どうすればいいのかな？ c-\でcoreを取れるんでしょうか？
#上でもshiroさんがspin lockでそういう現象があった(再現しない)って言ってるし
#psでpid拾って、gdbでスタックトレースを取得するとか
#そうか、なるほど。ちょっと試してみます。
#その前に、ログをみてどこで止まっているか見といた方がいいかも
#$ tail -5 ext/threads/test.log
test mutex-name, expects foo ==> ok
test mutex-specific, expects "hoge" ==> ok
test lock and unlock - no blocking, expects #t ==> ok
test mutex-state, expects (not-abandoned #<thread "root" runnable 0x9d3fd20> not-owned not-abandoned) ==> ok
test lock and unlock - blocking (simple spin-lock), expects ((put a) (get a) (put b) (get b) (put c) (get c)) ==>
#上でshiroさんが言ってたのと同じところっぽいですね
#(gdb) bt
#0 0x4001c424 in __kernel_vsyscall ()
#1 0x4027a3b5 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0
#2 0x40124668 in GC_stop_world () at pthread_stop_world.c:426
#3 0x4011793e in GC_stopped_mark (stop_func=0x40116d40 <GC_never_stop_func>)
at alloc.c:474
#4 0x40117c29 in GC_try_to_collect_inner (
stop_func=0x40116d40 <GC_never_stop_func>) at alloc.c:362
#5 0x40117e8c in GC_collect_or_expand (needed_blocks=20, ignore_off_page=0)
at alloc.c:1017
#6 0x4011d339 in GC_alloc_large (lb=80000, k=0, flags=0) at malloc.c:61
#7 0x4011d6d9 in GC_generic_malloc (lb=80000, k=0) at malloc.c:171
#8 0x4011d9bb in GC_core_malloc_atomic (lb=80000) at malloc.c:230
#9 0x401272fb in GC_malloc_atomic (bytes=80000) at thread_local_alloc.c:209
#10 0x400600df in Scm_NewVM (proto=0x97bdd20, name=0x989a770) at vm.c:188
#11 0x4020791e in ?? ()
#12 0x097bdd20 in ?? ()
#13 0x0989a770 in ?? ()
#14 0x00000000 in ?? ()#info threads すると?
#(gdb) info threads
2 Thread 0x40622b90 (LWP 15193) 0x4001c424 in __kernel_vsyscall ()
1 Thread 0x403f0260 (LWP 15156) 0x4001c424 in __kernel_vsyscall ()
でした。
#カレント・スレッドはどっちなんだろう??
#thread 2 としてから btするとどうですかね?
#やってみました。
#(gdb) thread 2
[Switching to thread 2 (Thread 0x40622b90 (LWP 15193))]#0 0x4001c424 in __kernel_vsyscall ()
(gdb) bt
#0 0x4001c424 in __kernel_vsyscall ()
#1 0x402b2aa7 in sigsuspend () from /lib/i686/cmov/libc.so.6
#2 0x4012487b in GC_suspend_handler_inner (
sig_arg=0x1e <Address 0x1e out of bounds>, context=0x40621a1c)
at pthread_stop_world.c:207
#3 0x40124905 in GC_suspend_handler (sig=30, info=0x4062199c,
context=0x40621a1c) at pthread_stop_world.c:142
#4 <signal handler called>
#5 0x402785d1 in pthread_cond_signal@@GLIBC_2.3.2 ()
from /lib/i686/cmov/libpthread.so.0
#6 0x40208009 in ?? ()
#7 0x0986faa0 in ?? ()
#8 0x00000000 in ?? ()#すると、最初のスタックトレースがスレッド#1ので、こっちがスレッド#2のってことですね
#GCの中でデッドロックしてるってことなのかなぁ
#うわ、gc中でデッドロックってことですね。これは厄介だなあ。
#手元の環境では、けっこうな頻度でthreadsのテストのところで引っかかるみたいです。
#Linuxはよくわからないんですけど、スレッド#1の方にsem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0 って行があって
#スレッド#2の方にpthread_cond_signal@@GLIBC_2.3.2 って行があるんだけど
#これって普通のことなのですかね?(つまり、GLIBCのバージョンが違うように見える)
#ぱっと見ひっかかっただけなので、頓珍漢なこと言ってるかもですが
#dsoのパスは同じに見えるので、エントリのバージョンじゃないかなあ。エントリごとにバージョンをつけられたんじゃなかったっけ?
#ふむ
#うちで再現させにくにのがきついなあ。
#上記の現象が出ているのは自宅サーバーなので、公開鍵をもらえればssh接続してテストしてもらうのは可能です。
##ext/threads/test.scmのthread-terminate!の呼び出し(一ヶ所)とその次のtest*式をコメントアウトして試してみてください。私の環境ではそれで刺さらなくなりました。
#GC中にcancelがかかると、Boehm GCの中でトラックしてるスレッドの数と実際のスレッドの数が合わなくなるのが原因です。GC_stop_world()でスレッド数を表示させてみると、刺さる時はスレッドが(メイン以外に)1本しかないのに、GCは2つスレッドを待とうとしています。
#で、本家の方でパッチは出てるんですか結構あちこち変更があるので、現段階で当てるべきかどうかちょっと迷います。試してはみますが。
#>libraさん 一筋縄ではいかなさそうですね。手元にOpenSolarisの環境を作ってみます。0.9に間に合うかどうかはわかりませんが。
Gauche > Archives > 2009/11/02