接續

我前天說到我要找時間查查到底是什麼原因造成PHP的Segmentation Fault，我想本篇文章的標題已經指名原因了，那我就結束這回合。

當然我還是在這邊紀錄一下流程以及解決方法，然後在除錯的過程中還順便解了一個PHPBrew的Bug，這個Bug就是關於./configure找不到libpcre(.a|.so)的問題，原因是出在於系統架構的判斷。

先不管這個，我之前說過只要preg_match()只要輸入的字串一長就會發生錯誤，所以我們朝PCRE Library進行。

觀察 ./configure 設定配置

我找了一個之前編譯的正常PHP所使用的配置，現在有問題的配置做比對。其中發現PCRE的設定方式不相同。

舊的配置關於PCRE的部份只有--with-pcre-regex，而新的配置則是--with-pcre-regex=/usr --with-pcre-dir=/usr。

新的--with-pcre-regex=/usr其實不影響執行，真正有問題的部份出在於--with-pcre-regex與--with-pcre-regex=/usr的對於實際編時所引入的函式庫不同。

--with-pcre-regex所代表的是編譯時引入PHP內建的PCRE函式庫，而--with-pcre-regex=/usr所代表的是引入外部的PCRE函式庫。

造成的原因是因為PHPBrew的版次問題所造成，它會檢查系統中是否已經有PCRE函式庫，如果已經存在就會自動在--with-pcre-regex後面加上prefix。

使用不同的函式庫

為了要測試原因是否是系統內建的問題，或者是只要引入外部PCRE就會出錯，所以我就另外編譯了新的PCRE函式庫作為測試。

• PCRE版本
  • 8.31-2 Ubuntu 13.10內建
  • 8.32 PHP 5.4.25內建
  • 8.34 自行編譯最新版

編譯過程我就省略，PHP 5.4.25以及自行編譯的PCRE都可以正常執行。最後結果就是系統內建的PCRE有問題，並且連帶系統內建的PHP 5.5.3都會出現同樣的問題。

解決方案

雖然不知道內建的PCRE究竟是哪邊出問題，不過我有兩種解決方法。不是移除系統內建的PCRE讓PHP用本身的函式庫，就是使用自行編譯的PCRE。

下面我就把我的PHPBrew安裝設定公開出來，因為我是使用自行編譯的PCRE所以在最後要指定函式庫位置。

phpbrew -d install 5.4.25 +default+db+openssl+iconv -- --with-pcre-regex=/opt/pcre