yosuke takadate
taten****@gmail*****
2011年 3月 4日 (金) 14:43:28 JST
UltraMonkey-L7
Fork中居様、近藤様、竹林様
高舘です。
情報ありがとうございます。
SSLProxyの件ですが、num_threadパラメータを10⇒1変更後
SSLProxy停止の問題は発生しておりません。
ただ、l7vsd停止は再発しており、皆様の助言通りSSLProxyと
本問題の関連性はないようです。
また、max_eventsの情報、非常に参考になりました。
前から気になっていた情報でしたので有り難いです。
関連して、単一URLによる簡易的な負荷掛けを実施し、
l7vsd稼働サーバのfdが最大値に到達した場合にも、l7vsd
プロセスが停止することはありませんでした。
本問題は、リソース影響で発生するものではないようです。
その後、発生時の状況を絞り込み、
l7vsd停止時のリクエストには、以下の
共通点があることがわかりました。
・POSTメソッド
・マルチパートリクエストである確率が高い(特にファイルアップロード処理)
・クライアントUserAgentはFirefox（Mozilla/5.0）、IEでは未だに起きていない
・ajaxでJavascriptから呼び出されるCGIである確率が高い
ブラウザ上からリクエストを発行し、
極稀に再現することを確認したのですが、
原因が特定できていない状況です。
> 中居様
>>>> (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=<value optimized out>) 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=<value optimized
>>>> out>, blocking=-1) at iomux.c:773
>>>> #9 0x000000000040bd04 in main (argc=2, argv=0x7fff6800c0f8) at l7vsd.c:
>>> 429
>>>>
>> ------------------------------------------
>
> cldata(client data)を新しいバッファに張り替えているところですね。
> もし出来ればconn.c:2923行目でcldataのアドレスを取得出来ますでしょうか?
> iomuxと云う管理構造体の初期化時にcldataは必ず作成されて、
> cldataのメモリを取得出来ない場合には
> error / can not allocate memory for buffer
> と、云うErrorLogを出力します。
> ただエラー出力した後は中断処理に入っていますので、使い回されることは
> 無いかと思います。
> #__libc_messageを出力するようにすれば、問題のエラーを取得出来るかも?
cldataのアドレスは取得できているので、
"error / can not allocate memory for buffer"という
エラーログは出力されておりません。
connの内容は以下のようになっています。
(gdb) print *conn
$1 = {lsock = 0x17b15160, srv = 0x17b151d0, dest = 0x17b23dc0, splice
= 0, caddr = {sin_family = 2,
sin_port = 53934, sin_addr = {s_addr = 3894339786}, sin_zero =
"\000\000\000\000\000\000\000"}, raddr = {
sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero =
"\000\000\000\000\000\000\000"},
vaddr = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0},
sin_zero = "\000\000\000\000\000\000\000"},
laddr = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0},
sin_zero = "\000\000\000\000\000\000\000"},
ciom = 0x17afe9a0, riom = 0x17afe9c0, proto = 6 '\006', state = 0,
cldata = 0x1808d0d0 "POST /HOGE/upload
HTTP/1.1\r\nX-Forwarded-For: 111.222.333.444\r\nHost:
hoge.jp:8831\r\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1;
ja; rv:1.9.2.12) Gecko/20101026"..., cldata_len = 20512,
cldata_bufsize = 20480, cmss = 1448, sorry_conn_flag = 0, old_dest =
0x0}
この状態で、conn.c:2923のfreeで落ちてしまうということは、
cldataへの格納時点で、(マルチパートリクエスト時に起きやすい
何らかの原因で)バッファ溢れが起きているのでしょうか。
MALLOC_CHECKなどでmessageを検出できるように試してみたいと思います。
助言ありがとうございました。
よろしくお願いします。