BugTrack/2358

XAMPPの特定バージョンで「テキスト整形のルール」 FormattingRules を表示できない†

ページ: BugTrack2
投稿者: umorigu
優先順位: 普通
状態: 完了
カテゴリー: 本体バグ
投稿日: 2014-12-26 (金) 05:38:35
バージョン: 1.5.0
リリース予定バージョン: 1.5.1

↑

メッセージ†

official:質問箱5/163 より

Windows 環境の XAMPP で再現を確認。

XAMPP v1.7.7 (Apache 2.2.21, PHP 5.3.8) →発生する
XAMPP v1.8.2 (Apache 2.4.4, PHP 5.4.27) →発生しない
XAMPP v1.8.3 (Apache 2.4.9, PHP 5.5.11) →発生しない

↑

回避策†

XAMPP のバージョンアップ
本文を編集し、注釈部分を削除する

正規表現モジュールとの相性バグか何かで、これと似たようなことが起きてるのかな？BugTrack2/237 注釈の文字が長いとApacheが停止する -- 2015-02-17 (火) 22:24:28
何らかの理由でサーバーの子プロセスが再起動させられてる？かんじなので、過剰にチェックをしないよう、
注釈の中味チェックをOR分岐以外ではバックトラック禁止＆注釈開始と同じ文字列がある時だけ～と言明を足して繰り返し突入を制限する
```
 ((?>(?=$\()(?R)|(?!$\)).)*) # (1) note body
```
にlib/make_link.phpの注釈用パターンを差し替えると、FormattingRulesを書き換えなくても回避できてるっぽいです。他の環境（特に、使える正規表現が限定的な古いPHPとか）でも問題なく動くのか～のチェックがまだ不十分ですが、取り急ぎ報告を。 -- 2015-03-19 (木) 21:27:57
- ちなみに。言明だけだと、編集時に枠の下へルールを同時表示する「テキスト整形のルールを表示する」パターンでは回避できなかったり。バックトラック禁止だけだと、BugTrack/765を回避できなさそうだったり。 -- 2015-03-19 (木) 21:27:57
- 1.5.0オリジナルは
```
((?:(?R)|(?!\)\)).)*) # (1) note body
```
  となっていますね。"(?R)" は再帰で、言明(assertion)とは正規表現の用語なのですね。難しい・・・注釈に再帰が必要なのか？とも思いますが過去の議論を見るとネストする前提で実装されているようです -- umorigu 2015-03-24 (火) 01:50:44
問題の発生していたXAMPP v1.7.7 の環境で正常動作することを確認しました。また、PHP4.1.2でも動作したので、ご提案の案を採用します。ありがとうございました -- umorigu 2015-03-25 (水) 02:42:08

同じく注釈の長さの問題で原因不明で停止する問題に苦しんでいましたが、色々調べた結果行き着いた対策を書いておきます。マッチングのオプションに u をつけることです（※ UTF-8 版を使っています）。具体的には make_link.php の 95 行目の '/x' を '/xu' にしました。根本的な解決ではないようで、許容可能な文字が２．５倍ぐらいになる程度のようですけど。 -- トゥイー 2015-03-30 (月) 18:12:02
- 以下、参考までに検証のために使ったソースコードを張っておきます。文字列の長さを変えてみたり、/x を /xu にしてみたりできます。 -- トゥイー 2015-03-30 (月) 18:18:44
```
<?php
$string = "((１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４５６７８９０１２３４))";
preg_match('/$\(((?:(?R)|(?!$\)).)*)\)\)/x', $string);
echo "SUCCESS";
?>
```
いろいろ試してて疑問だったのがブラウザからアクセスする場合は落ちるけど、コマンドラインで php.exe や php-cgi.php から呼び出した場合は正常に応答が返ってくること。なんでだろうか？ -- トゥイー 2015-03-30 (月) 18:20:00
- テスト実装をありがとうございます。
  このコードで確認すると、新実装+PHP5.6であっても、注釈の中が日本語文字200文字(UTF8で600bytes)ぐらいになると失敗しますね。
  旧実装とuオプションで限度が上がることも確認できました。
  EUC-JPであることもあるので、今の実装を使いますが、今後UTF-8前提になった時にuオプションを使うことで文字上限を緩和できたりパフォーマンスが上がることがあるかもしれません。参考にします -- umorigu 2015-03-30 (月) 22:17:16
http://php.net/manual/ja/reference.pcre.pattern.modifiers.php
u (PCRE_UTF8)

この修正子は、Perl 非互換な PCRE の機能を有効にします。パターンと対象文字列は、 UTF-8 として処理されます。この修正子は、UNIX では PHP 4.1.0 以降、Win32 では PHP 4.2.3 以降で使用可能です。また、PHP 4.3.5 以降では、パターンの UTF-8 としての妥当性も確認されます。
らしい~~ので、BugTrack/761と同じく今のまま（PHP 4.1.2からサポート）では対応が難しそう~~ですね。 -- 2015-03-30 (月) 19:08:21
- 訂正。単語検索のように正規表現パターンの文字列を環境に合わせて可変させれば、使うことは可能でしたね・・・・・。 -- 2015-03-30 (月) 19:27:11
Apacheのスタックサイズ不足ではないでしょうか。
httpd.conf にて、
```
<IfModule mpm_winnt_module>
    ThreadStackSize 8*1024*1024
</IfModule>
```
とするといいかも知れません。
ref. https://bugs.php.net/bug.php?id=47689 -- nao-pon 2015-04-04 (土) 22:05:08
- PukiWiki 側で対処するのは難しいかも知れませんね。 -- nao-pon 2015-04-04 (土) 22:07:58
BugTrack2/240のように可能な限り最短マッチで～という指示をgit:b342c1e787bf0d86aea9c24b5f2aebdb5692498aの変更部分へさらに追加すると、落ちるまでの限度がいくらかマシになる気がしなくもないかも -- 2015-04-22 (水) 20:05:13

total:
today:
yesterday:
now: 1

XAMPPの特定バージョンで「テキスト整形のルール」 FormattingRules を表示できない†

メッセージ†

回避策†

最新の16件