From tatenaga ＠ gmail.com Tue Feb 22 08:37:47 2011 From: tatenaga ＠ gmail.com (yosuke takadate) Date: Tue, 22 Feb 2011 08:37:47 +0900 Subject: [Ultramonkey-l7-users 381] Re: =?iso-2022-jp?b?bDd2c2QbJEIlVyVtJTslOSQsTW4kQSRrTGRCahsoQg==?= Message-ID: 竹林様 高舘です。 ご対応頂き、ありがとうございます。 解析の状況はいかがでしょうか？ 追加情報ですが、こちらの環境ではapache-log4cxxを 標準ディレクトリ以外にインストールしており、この点が インストールマニュアルと異なる点です。 リンク情報は下記のようになります。 # ldd /usr/sbin/l7vsd libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00002b7c9c9c7000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00002b7c9cc07000) librt.so.1 => /lib64/librt.so.1 (0x00002b7c9cea5000) liblog4cxx.so.10 => /usr/local/apache-log4cxx/lib/liblog4cxx.so.10 (0x00002b7c9d0af000) libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00002b7c9d4a5000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b7c9d6bf000) libdb-4.3.so => /lib64/libdb-4.3.so (0x00002b7c9d8f8000) libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002b7c9dbee000) liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002b7c9de28000) libexpat.so.0 => /lib64/libexpat.so.0 (0x00002b7c9e037000) libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00002b7c9e259000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7c9e480000) libboost_regex.so.2 => /usr/lib64/libboost_regex.so.2 (0x00002b7c9e69c000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b7c9e947000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b7c9eb4b000) libm.so.6 => /lib64/libm.so.6 (0x00002b7c9ee4c000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b7c9f0cf000) libc.so.6 => /lib64/libc.so.6 (0x00002b7c9f2dd000) /lib64/ld-linux-x86-64.so.2 (0x00002b7c9c7aa000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7c9f635000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b7c9f839000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002b7c9fa4e000) libssl.so.6 => /lib64/libssl.so.6 (0x00002b7c9fc68000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b7c9feb4000) libicui18n.so.36 => /usr/lib64/libicui18n.so.36 (0x00002b7ca0205000) libicuuc.so.36 => /usr/lib64/libicuuc.so.36 (0x00002b7ca054a000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b7ca087f000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b7ca0aae000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b7ca0d43000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b7ca0f45000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002b7ca116b000) libicudata.so.36 => /usr/lib64/libicudata.so.36 (0x00002b7ca137f000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b7ca1f2f000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b7ca2137000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b7ca233a000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b7ca2552000) -- 問題の解決の為、UltraMonkey-L7のバージョン3への移行も 視野に入れております。マルチスレッド化などl7vsdに大きく手が入った バージョン3への移行メリットはやはりございますでしょうか？ (同じような問題が内在している可能性はあるでしょうか？) 2011年2月15日21:44 Shinya TAKEBAYASHI : > 高舘さま > > > 竹林です． > 返信が遅くなり，すみません． > > 下記，解析してみます． > 少し時間をいただけますか． > > yosuke takadate wrote in message z74RfjbGb5ETK8PHnq8zXBhOzgbgJJ9 ＠ mail.gmail.com> > *** Subject: [Ultramonkey-l7-users 374] Re: l7vsdプロセスが落ちる問題 > *** Date: 2011/02/14 19:29:23 >> 高舘と申します。 >> >> 表題の件、coreファイルを解析しましたので >> 追加でご報告します。 >> >> >> (1)ログレベルdebugで落ちる場合 >> 下記のパッチは適用済みです。 >> http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/develop/20100802/000627.html >> >> Program terminated with signal 6, Aborted. >> #0 0x00002b4625f54265 in raise () from /lib64/libc.so.6 >> #1 0x00002b4625f55d10 in abort () from /lib64/libc.so.6 >> #2 0x00002b4625f8e84b in __libc_message () from /lib64/libc.so.6 >> #3 0x00002b462600d10f in __stack_chk_fail () from /lib64/libc.so.6 >> #4 0x000000000041e92a in l7vs_service_remove_conn >> (srv=0x6f632a206e6e6f63, conn=0x5f7376376c207463) at service.c:1410 >> #5 0x0000000000424db3 in l7vs_conn_destroy (conn=0x5de2bd0) at conn.c:549 >> #6 0x000000000040c999 in l7vs_iomux_poll (timo=> out>, blocking=-1) at iomux.c:752 >> #7 0x000000000040bd04 in main (argc=2, argv=0x7fff4aabbde8) at l7vsd.c: > 429 >> >> バッファオーバーフローを検知してのAbortでしょうか？ >> こちらは更に調査しておりますが、解決は厳しい状況です。 >> >> >> >> (2)ログレベルwarnで落ちる場合 >> >> Program terminated with signal 6, Aborted. >> #0 0x00002b30736de265 in raise () from /lib64/libc.so.6 >> #1 0x00002b30736dfd10 in abort () from /lib64/libc.so.6 >> #2 0x00002b307371884b in __libc_message () from /lib64/libc.so.6 >> #3 0x00002b307372030f in _int_free () from /lib64/libc.so.6 >> #4 0x00002b307372076b in free () from /lib64/libc.so.6 >> #5 0x000000000042dc82 in l7vs_conn_send (iom=0x1130e980, >> dest_fd=) at conn.c:2923 >> #6 0x000000000042e78f in l7vs_conn_sending (iom=0x1130e980, >> another_iom=0x1130e960) at conn.c:1690 >> #7 0x000000000042f55f in l7vs_conn_rs_callback (iom=0x1130e980) >> at conn.c:2014 >> #8 0x000000000040c8f8 in l7vs_iomux_poll (timo=> out>, blocking=-1) at iomux.c:773 >> #9 0x000000000040bd04 in main (argc=2, argv=0x7fff6800c0f8) at l7vsd.c: > 429 >> >> 2重freeでしょうか？ >> if文をはさめば解決するかもしれません。 >> >> >> 似たような問題が発生した方、回避方法など知見をお持ちの方がいましたら >> ご教示頂けたらと思います。 >> >> よろしくお願い致します。 >> >> On Wed, 9 Feb 2011 16:25:44 +0900 >> yosuke takadate wrote: >> >> > 高舘と申します。 >> > l7vsdプロセスが落ちるという問題が発生しており >> > 原因を調査中です。 >> > >> > >> > 環境 >> > CentOS5.5 (2.6.18-194.32.1.el5xen x86_64) >> > UltraMonkey-l7 2.1.3 >> > 起動モード: non-blocking >> > heartbeatによるHA構成 >> > -l7vsdはクローンで正副2台で稼働 >> > -レプリケーションは有効 >> > >> > 設定 >> > ※設定ファイルを別途添付させて頂きます >> > >> > 発生頻度 >> > ほぼ1日に1回のペース >> > アクセスがあまりない時期に落ちることはありませんでしたが >> > 定量的なアクセスの増加時に発生するようになりました >> > >> > ログ >> > ログレベルはすべて"warn"レベルにしておりましたが、 >> > 停止前にログは出力されておりませんでした。 >> > 一度"debug"レベルに変更してみたのですが、別の問題（恐らく下記URLが原因↓） > で >> > l7vsdプロセスが停止してしまう状況となりログからの調査が難しくなっております >> > http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/develop/20100802/000627.html >> > >> > >> > >> > 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >> > 投入して静観中です。 >> > >> > 似たような問題が発生した方、回避方法など知見をお持ちの方がいましたら >> > ご教示頂けたらと思い、ご連絡させて頂きました。 >> > >> > よろしくお願い致します。 >> >> _______________________________________________ >> Ultramonkey-l7-users mailing list >> Ultramonkey-l7-users ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users > > > ----------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail: takebayashi.shinya ＠ oss.ntt.co.jp > GPG ID: 395EFCE8 > GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 > ----------------------------------------------------------- > From kondo.hideaki ＠ nttcom.co.jp Tue Feb 22 09:51:23 2011 From: kondo.hideaki ＠ nttcom.co.jp (Hideaki KONDO) Date: Tue, 22 Feb 2011 09:51:23 +0900 Subject: [Ultramonkey-l7-users 382] Re: =?iso-2022-jp?b?bDd2c2QbJEIlVyVtJTslOSQsTW4kQSRrTGRCahsoQg==?= In-Reply-To: References: Message-ID: <4D63088B.6080001@nttcom.co.jp> 高舘様 お疲れ様です。 近藤と申します。 直接のUM-L7開発からは遠ざかっているので、あまり参考に ならないかも知れませんが、Ver.2.1.x頃の状況を知るものとして 障害状況から考えて、環境的に少々気になるところがあります。 お時間があれば、切り分けの意味で試してみては如何でしょうか。 (1) 起動モードについては、「non-blocking」を選択されておりますが、 性能的には1〜2割程度しか変わらず、CPU使用率やおそらく安定性( 諸事情から動作検証はblockingモードの方が多くされてきていました） の面でも有利な「blocking」モードを試して切り分けされては如何で しょうか。 この起動モードが、オーバーフローや二重free等の障害に間接的に 関係している可能性があるかも知れません。 もしl7vsdプロセスダウンが発生しなくなったり、発生頻度に変化が あれば、関係している可能性が高いと思います。 (2) レプリケーション機能を「有効」にして利用されておりますが、 可能であれば一度「無効」にして様子をみては如何でしょうか。 こちらもl7vsdプロセスダウンの発生頻度の違いを確認した方がよい かと思います。 開発当時はそれなりに動作検証がなされてきてましたが、私の知る限り 長期間使用した実績がなく、あまり利用を推奨していなかった記憶が あります。 そもそもこの機能は、使用するプロトコルモジュールによって 意味のあるものとないものが存在し、無理に設定しなくても運用上 問題ない場合が多いかと思います。 以上、少しでも参考になればと思い、レスさせて頂きました。 >>>> 高舘と申します。 >>>> l7vsdプロセスが落ちるという問題が発生しており >>>> 原因を調査中です。 >>>> >>>> >>>> 環境 >>>> CentOS5.5 (2.6.18-194.32.1.el5xen x86_64) >>>> UltraMonkey-l7 2.1.3 >>>> 起動モード: non-blocking >>>> heartbeatによるHA構成 >>>> -l7vsdはクローンで正副2台で稼働 >>>> -レプリケーションは有効 >>>> >>>> 設定 >>>> ※設定ファイルを別途添付させて頂きます >>>> >>>> 発生頻度 >>>> ほぼ1日に1回のペース >>>> アクセスがあまりない時期に落ちることはありませんでしたが >>>> 定量的なアクセスの増加時に発生するようになりました >>>> >>>> ログ >>>> ログレベルはすべて"warn"レベルにしておりましたが、 >>>> 停止前にログは出力されておりませんでした。 >>>> 一度"debug"レベルに変更してみたのですが、別の問題（恐らく下記URLが原因↓） >> で >>>> l7vsdプロセスが停止してしまう状況となりログからの調査が難しくなっております >>>> http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/develop/20100802/000627.html >>>> >>>> >>>> >>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>> 投入して静観中です。 >>>> >>>> 似たような問題が発生した方、回避方法など知見をお持ちの方がいましたら >>>> ご教示頂けたらと思い、ご連絡させて頂きました。 >>>> >>>> よろしくお願い致します。 -- Hideaki Kondo From tateishi.katsuyuki ＠ oss.ntt.co.jp Tue Feb 22 09:55:47 2011 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Tue, 22 Feb 2011 09:55:47 +0900 (JST) Subject: [Ultramonkey-l7-users 383] Re: =?iso-2022-jp?b?bDd2c2QbJEIlVyVtJTslOSQsTW4kQSRrTGRCahsoQg==?= In-Reply-To: References: Message-ID: <20110222.095547.1428731976638006133.tateishi.katsuyuki@oss.ntt.co.jp> 立石と申します。おはようございます。 横からすみません yosuke takadate -san wrote: > 追加情報ですが、こちらの環境ではapache-log4cxxを > 標準ディレクトリ以外にインストールしており、この点が > インストールマニュアルと異なる点です。 > リンク情報は下記のようになります。 > > # ldd /usr/sbin/l7vsd > libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00002b7c9c9c7000) > libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00002b7c9cc07000) > librt.so.1 => /lib64/librt.so.1 (0x00002b7c9cea5000) > liblog4cxx.so.10 => > /usr/local/apache-log4cxx/lib/liblog4cxx.so.10 (0x00002b7c9d0af000) リンクできているので問題ないと思います。 > 問題の解決の為、UltraMonkey-L7のバージョン3への移行も > 視野に入れております。マルチスレッド化などl7vsdに大きく手が入った > バージョン3への移行メリットはやはりございますでしょうか？ > (同じような問題が内在している可能性はあるでしょうか？) いずれ正式にアナウンスがあると思いますが、v3はまだ安定しておらず、 移行はお勧めできません。 良い情報がなくて申し訳ないのですが、以上です。 -- TATEISHI Katsuyuki From kondo.hideaki ＠ nttcom.co.jp Tue Feb 22 09:57:19 2011 From: kondo.hideaki ＠ nttcom.co.jp (Hideaki KONDO) Date: Tue, 22 Feb 2011 09:57:19 +0900 Subject: [Ultramonkey-l7-users 384] Re: =?iso-2022-jp?b?bDd2c2QbJEIlVyVtJTslOSQsTW4kQSRrTGRCahsoQg==?= In-Reply-To: <4D63088B.6080001@nttcom.co.jp> References: <4D63088B.6080001@nttcom.co.jp> Message-ID: <4D6309EF.4000806@nttcom.co.jp> 高舘様 近藤です。 すみません。 すでに(1)の起動モードについては、試されていたのですね。 >>>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>>> 投入して静観中です。 ブロッキングモードで動作させた場合、l7vsdプロセスダウン発生頻度に 変化等があるようであれば、共有頂ければ、竹林さん等の原因解析にも 少し役立つと思いますので、よろしくお願いします。 (2011/02/22 9:51), Hideaki KONDO wrote: > > 高舘様 > > お疲れ様です。 > 近藤と申します。 > > 直接のUM-L7開発からは遠ざかっているので、あまり参考に > ならないかも知れませんが、Ver.2.1.x頃の状況を知るものとして > 障害状況から考えて、環境的に少々気になるところがあります。 > お時間があれば、切り分けの意味で試してみては如何でしょうか。 > > (1) > 起動モードについては、「non-blocking」を選択されておりますが、 > 性能的には1〜2割程度しか変わらず、CPU使用率やおそらく安定性( > 諸事情から動作検証はblockingモードの方が多くされてきていました） > の面でも有利な「blocking」モードを試して切り分けされては如何で > しょうか。 > この起動モードが、オーバーフローや二重free等の障害に間接的に > 関係している可能性があるかも知れません。 > もしl7vsdプロセスダウンが発生しなくなったり、発生頻度に変化が > あれば、関係している可能性が高いと思います。 > > (2) > レプリケーション機能を「有効」にして利用されておりますが、 > 可能であれば一度「無効」にして様子をみては如何でしょうか。 > こちらもl7vsdプロセスダウンの発生頻度の違いを確認した方がよい > かと思います。 > 開発当時はそれなりに動作検証がなされてきてましたが、私の知る限り > 長期間使用した実績がなく、あまり利用を推奨していなかった記憶が > あります。 > そもそもこの機能は、使用するプロトコルモジュールによって > 意味のあるものとないものが存在し、無理に設定しなくても運用上 > 問題ない場合が多いかと思います。 > > 以上、少しでも参考になればと思い、レスさせて頂きました。 > >>>>> 高舘と申します。 >>>>> l7vsdプロセスが落ちるという問題が発生しており >>>>> 原因を調査中です。 >>>>> >>>>> >>>>> 環境 >>>>> CentOS5.5 (2.6.18-194.32.1.el5xen x86_64) >>>>> UltraMonkey-l7 2.1.3 >>>>> 起動モード: non-blocking >>>>> heartbeatによるHA構成 >>>>> -l7vsdはクローンで正副2台で稼働 >>>>> -レプリケーションは有効 >>>>> >>>>> 設定 >>>>> ※設定ファイルを別途添付させて頂きます >>>>> >>>>> 発生頻度 >>>>> ほぼ1日に1回のペース >>>>> アクセスがあまりない時期に落ちることはありませんでしたが >>>>> 定量的なアクセスの増加時に発生するようになりました >>>>> >>>>> ログ >>>>> ログレベルはすべて"warn"レベルにしておりましたが、 >>>>> 停止前にログは出力されておりませんでした。 >>>>> 一度"debug"レベルに変更してみたのですが、別の問題（恐らく下記URLが原因↓） >>> で >>>>> l7vsdプロセスが停止してしまう状況となりログからの調査が難しくなっております >>>>> http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/develop/20100802/000627.html >>>>> >>>>> >>>>> >>>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>>> 投入して静観中です。 >>>>> >>>>> 似たような問題が発生した方、回避方法など知見をお持ちの方がいましたら >>>>> ご教示頂けたらと思い、ご連絡させて頂きました。 >>>>> >>>>> よろしくお願い致します。 > -- Hideaki Kondo From kondo.hideaki ＠ nttcom.co.jp Tue Feb 22 10:19:59 2011 From: kondo.hideaki ＠ nttcom.co.jp (Hideaki KONDO) Date: Tue, 22 Feb 2011 10:19:59 +0900 Subject: [Ultramonkey-l7-users 385] Re: =?iso-2022-jp?b?bDd2c2QbJEIlVyVtJTslOSQsTW4kQSRrTGRCahsoQg==?= In-Reply-To: <4D6309EF.4000806@nttcom.co.jp> References: <4D63088B.6080001@nttcom.co.jp> <4D6309EF.4000806@nttcom.co.jp> Message-ID: <4D630F3F.3010107@nttcom.co.jp> 高舘様 近藤です。 度々すみません。 もう一点補足です。 >> そもそもこの機能は、使用するプロトコルモジュールによって >> 意味のあるものとないものが存在し、無理に設定しなくても運用上 >> 問題ない場合が多いかと思います。 先に送付されておりました設定ファイル(l7directord.cf)を 参照させて頂きましたら、プロトコルモジュールはすべて 「sessionless」でしたので、特別な意図がない限り、 レプリケーション機能は「無効」でよいかと思います。 レプリケーション機能は、sslidモジュールやipモジュールなど パーシステンス系のモジュールを使用する場合に、ActからSby側へ パーシステンス情報を障害切り替え時に備えて定期的に同期する ために実装されていたはずですので。 以上です。 (2011/02/22 9:57), Hideaki KONDO wrote: > > 高舘様 > > 近藤です。 > > すみません。 > すでに(1)の起動モードについては、試されていたのですね。 > >>>>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>>>> 投入して静観中です。 > > ブロッキングモードで動作させた場合、l7vsdプロセスダウン発生頻度に > 変化等があるようであれば、共有頂ければ、竹林さん等の原因解析にも > 少し役立つと思いますので、よろしくお願いします。 > > > (2011/02/22 9:51), Hideaki KONDO wrote: >> >> 高舘様 >> >> お疲れ様です。 >> 近藤と申します。 >> >> 直接のUM-L7開発からは遠ざかっているので、あまり参考に >> ならないかも知れませんが、Ver.2.1.x頃の状況を知るものとして >> 障害状況から考えて、環境的に少々気になるところがあります。 >> お時間があれば、切り分けの意味で試してみては如何でしょうか。 >> >> (1) >> 起動モードについては、「non-blocking」を選択されておりますが、 >> 性能的には1〜2割程度しか変わらず、CPU使用率やおそらく安定性( >> 諸事情から動作検証はblockingモードの方が多くされてきていました） >> の面でも有利な「blocking」モードを試して切り分けされては如何で >> しょうか。 >> この起動モードが、オーバーフローや二重free等の障害に間接的に >> 関係している可能性があるかも知れません。 >> もしl7vsdプロセスダウンが発生しなくなったり、発生頻度に変化が >> あれば、関係している可能性が高いと思います。 >> >> (2) >> レプリケーション機能を「有効」にして利用されておりますが、 >> 可能であれば一度「無効」にして様子をみては如何でしょうか。 >> こちらもl7vsdプロセスダウンの発生頻度の違いを確認した方がよい >> かと思います。 >> 開発当時はそれなりに動作検証がなされてきてましたが、私の知る限り >> 長期間使用した実績がなく、あまり利用を推奨していなかった記憶が >> あります。 >> そもそもこの機能は、使用するプロトコルモジュールによって >> 意味のあるものとないものが存在し、無理に設定しなくても運用上 >> 問題ない場合が多いかと思います。 >> >> 以上、少しでも参考になればと思い、レスさせて頂きました。 >> >>>>>> 高舘と申します。 >>>>>> l7vsdプロセスが落ちるという問題が発生しており >>>>>> 原因を調査中です。 >>>>>> >>>>>> >>>>>> 環境 >>>>>> CentOS5.5 (2.6.18-194.32.1.el5xen x86_64) >>>>>> UltraMonkey-l7 2.1.3 >>>>>> 起動モード: non-blocking >>>>>> heartbeatによるHA構成 >>>>>> -l7vsdはクローンで正副2台で稼働 >>>>>> -レプリケーションは有効 >>>>>> >>>>>> 設定 >>>>>> ※設定ファイルを別途添付させて頂きます >>>>>> >>>>>> 発生頻度 >>>>>> ほぼ1日に1回のペース >>>>>> アクセスがあまりない時期に落ちることはありませんでしたが >>>>>> 定量的なアクセスの増加時に発生するようになりました >>>>>> >>>>>> ログ >>>>>> ログレベルはすべて"warn"レベルにしておりましたが、 >>>>>> 停止前にログは出力されておりませんでした。 >>>>>> 一度"debug"レベルに変更してみたのですが、別の問題（恐らく下記URLが原因↓） >>>> で >>>>>> l7vsdプロセスが停止してしまう状況となりログからの調査が難しくなっております >>>>>> http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/develop/20100802/000627.html >>>>>> >>>>>> >>>>>> >>>>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>>>> 投入して静観中です。 >>>>>> >>>>>> 似たような問題が発生した方、回避方法など知見をお持ちの方がいましたら >>>>>> ご教示頂けたらと思い、ご連絡させて頂きました。 >>>>>> >>>>>> よろしくお願い致します。 >> -- Hideaki Kondo