ページ数が増えるとAutoLinkが原因でmake_link()が正常に動作しない †
- ページ: BugTrack2
- 投稿者: nao-pon, asari?
- 優先順位: 普通
- 状態: 保留
- カテゴリー: 本体バグ
- 投稿日: 2005-06-20 (月) 20:04:57
- バージョン:
メッセージ (from nao-pon) †
ページ数が増えると、AutoLink の正規表現が原因で、make_link()が正常に動作しなくなり、空白を返します。
結果的にページが正常に表示されなくなります。
ページ数は5400ページほど、autolink.datのサイズが 38KB ほどで、この問題が出ています。
原因は解りませんが、正規表現パターンが大きすぎるのが原因かもしれません。
PHP: パターン構文 - Manual（http://www.php.net/manual/ja/reference.pcre.pattern.syntax.php）の以下の記述は関係あるのかな？
再帰的パターン
一つのパターン中に 15 以上のキャプチャ用サブパターンを用いると、PCRE は 再帰を行っている間のデータ保存用に追加の記憶領域を確保する必要が あります。
記憶領域が確保できない場合、メモリ不足エラーを再帰の内側から 出力する手段がないため、最初の 15 個のキャプチャ用サブパターンに ついてのみデータが保存されます。
テスト環境 †
- OS
- Vine Linux 3.1
- Apache
- 1.3.33
- PHP
- 4.3.11
- PukiWiki
- 1.4.5_1
メッセージ (from asari, BugTrack2/105) †
データベース的な使い方をしようと思い、スクリプトを使ってページを 10000
件ほど追加したところ、
デフォルト表示の部分とプラグインの部分をのぞいてページが表示されない状態になりました。
cache/autolink.dat を削除するとページ編集時に一時的に見えるようになったので、
autolink 周りが怪しいと思いました。
関連しそうな pukiwiki.ini.php の設定項目は:
$autolink = 8;
ちなみに、 cache/autolink.dat のサイズは、 45KB 程度です。
$autolink = 0;
とすると、正常に表示されるようになりました。
CVS版 (ただし、 iconv で UTF-8 に変換済み) でも修正されていないことを確認しました。 BugTrack2/44 と重複しているかとも思ったのですが、違うかもです。 -- asari?
テスト環境 †
- OS
- Mac OS X "Tiger" 10.4.2
- Apache
- 2.0.54
- PHP
- 5.0.4
- PukiWiki
- CVS
こめんと †
AutoLink の正規表現を分割して処理する例 (from nao-pon) †
コメント †
こめんと †
- ページ数が多くなるとAutoLinkが正常に機能しないという問題ですが、1.4.6でも起きました。AutoLink自体のロジックを見直す必要があるように思いますが・・・ -- よっちゃん?
- official:質問箱3/442 --
- ページ数が多くなるとAutoLinkが正常に機能しない問題について、1.4.7でも起きました(文書数26,995, cache/autolink.dat 218,090byte)。AutoLink機能を使い続けたいのですが回避策はありますか? -- puga?
- official:質問箱4/40 特定のページをautolink.dat の正規表現に含めたくない --
- こちらでも1.4.7でautolink.datのサイズが 38KB ほどで内容が表示されなくなりました。重要度普通になっていますが，他の頁にもあったように，スパム攻撃にも使えるし，utf-8環境ではどうしてもファイル名が長くなるので，このバグは早急に解決して欲しいです。また，インストールの頁などにこの問題点の記載が必要では？ここにたどり着くまでずいぶん悩みました。 -- kaz?
- 上記にあるように、phpの正規表現モジュール(pcre?)に依存した現象です。今のところ対策が分かっていません。kaz?さん直して～^^;
現実問題として、FAQとかその他インストールのページとかに注意事項として書いておいた方がよさそうですね。 -- ぃぉぃぉ
- デフォルトではAutolink無効にしておいて、pukiwiki.ini.phpのAutolinkの部分のコメントにAutolink有効の場合の問題点を記載しておいてはどうかな? -- ぃぉぃぉ
- 根本的な解決ができるまで，エラー処理はできないのでしょうか。正規表現モジュールが上限に達した(？)ときに，Autolinkを無効にしてその旨警告するというような処理ですが・・・kaz?
- もし次のように正規表現パターンを書き換えた場合に、問題がでる環境ってあるのでしょうか。
WebTrack\/(?:
1(?:0|1|2|3|4|5|6|7|8|9)?
|2(?:0|1|2|3|4|5|6|7|8|9)?
|3(?:0|1|2|3|4|5|6|7|8)?
|4(?:0|1|2|3|4|5|6|7|8|9)?
|5(?:0|1|2|3|4|5|6|7|8|9)?
|6(?:0|2|3|4|6|7|8|9)?
|7(?:0|1|2|3|4|5|6(?:\/てすと)?|7|8|9)?
|8(?:0)?
|9
)
上を下に（改行位置がややいい加減）。
WebTrack\/(?:
1[0123456789]?
|2[0123456789]?
|3[012345678]?
|4[0123456789]?
|5[0123456789]?
|6[02346789]?
|7(?:0|1|2|3|4|5|6(?:\/てすと)?|7|8|9)?
|8[0]?
|9
)
$result = generate_trie_regex($auto_pages) の結果を置換えているのがバレバレなんですが（つまり対処療法であって、根本解決ではない）。
ちなみに(?:0|1|2) を[012] にしようと思った理由は、パターン構文（http://jp2.php.net/manual/ja/reference.pcre.pattern.syntax.php）のパフォーマンスに
パターンに記述可能な要素のうち、幾つかの要素は、他の要素よりも 効率的に処理されます。
(a|e|i|o|u) のような選択肢の集合よりも [aeiou] のような文字クラスの方が効率的です。
とあったからです。サブパターンの数を減らすのにも少しは役立ちそうだったので。
余談ですが、このページの最適化後が今の生成パターンに似ているんですけど、もし正規表現パターンをそのページの最適化前のような状態（ページ名とページ名の間に'|'を挟んだだけの物に...）にして、（時間はかかっても）動くのなら「速度とサブパターン数のバランスをどこで取るのか」という問題に限定できるんだけど（そうでなければ、他の原因を探さねば）。 --
- この問題は未解決という理解であっておりますでしょうか？ -- Mike?
- 出来れば分かり易い位置に書いててほしかった。オートリンク前提だったので今から全ページ修正しなきゃorz --
- 関連?: BugTrack2/311 --
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
