[PHP-dev 1454] Re: max_execution_time を設定すると Apache が SIGABRT で終了する

[Moriyoshi Koizumi]

小泉です。

本件ですが、本家のメーリングリストでしれっと触れてみたら以下のような話になりました。

http://news.php.net/php.internals/43357

以上、参考になれば。


2009/3/16 Moriyoshi Koizumi <mozo ＠ mozo.jp>:
> すみません、ファイルに一部余計なものが含まれていました。
> これを当ててください。
>
> よろしくお願いします。
>
> 2009/3/16 Moriyoshi Koizumi <mozo ＠ mozo.jp>:
>> 小泉です。
>>
>> よくよく見てみたら、apache
>> SAPIでは下記のマクロの中でシグナルをブロックするハンドラに飛ばしていたのですが、apache2handler
>> SAPIでは何もしていませんでした。なのでそれが原因のような気がします。
>>
>> というわけでパッチを作成してみました。これを当てることで問題は回避されるでしょうか?
>>
>> 2009/3/16 Moriyoshi Koizumi <mozo ＠ mozo.jp>:
>>> 小泉です。
>>>
>>> お返事が遅くなってすみません (相変わらずです。。。)
>>>
>>> 可能であれば本家のバグ管理システムに報告していただけると助かります。
>>>
>>> http://bugs.php.net/
>>>
>>> さて、問題が発生していると思われる状況はどのようにすれば再現できますでしょうか。再現のためのコードまたは手順をご教示ください。
>>>
>>> malloc(3) 系の libc 関数は確かに非同期シグナルセーフではありませんが、emalloc() や efree() といった関数は
>>> libc の関数そのものではなく、PHP
>>> の側で用意しているアロケータです。これらの関数でも、クリティカルセクションの中でシグナルをブロックしているはず
>>> (HANDLE_BLOCK_INTERRUPTIONS / HANDLE_UNBLOCK_INTERUPTIONS)
>>> なので、そのような状況が発生するとは考えにくいです。むしろ、heap corruptionが発生しているという可能性はないですか?
>>>
>>>> そもそも、原則としてシグナルハンドラ中はアトミックな操作しか
>>>> 行ってはいけないはずですが、それが破られているのが原因だと考えられます。
>>>
>>> シグナルを適切にブロックしていればその限りではないと思いますが…。あまりシグナルハンドラ中であれこれやらないほうがいいのがベストプラクティスといえばその通りと思います。
>>>
>>> スマートな回避策があるとすれば、クリティカルセクションに入れるべきものが入ってない状況を回避するということになるでしょうか。
>>>
>>
>