Ubuntu上的apache、php5、mysql5都已经安装完毕了，phpMyAdmin也能够管理数据库了，接下来就是把以前apache上的程序再运行起来了。第一个Brim很顺利，除了和win下一样会有notice错误报告；第二个是mantis，一个bug跟踪系统，在这里就遇到了问题。
mantis的数据库配置正常，apache的虚拟目录配置也正常，访问/mantis时却是个空白页，php的error_reporting设置的是E_ALL，error_log和display_log都打开着呢，怎么会不显示内容呢。故意加了个语法错误在index.php中，发现浏览时会提示语法错误，errorlog中也有相应的内容。但就是正常访问的时候既不显示内容，也不提示错误，errorlog中也是没有变化。
于是开始跟踪代码，mantis 0.19.2，虽然include比较多，但是很容易就判断出：我的机器上尚存有保留的登录记录，因此index.php判断出登录状态之后就会把页面跳转到main_page.php，而问题极有可能就是出现在这个跳转上：
跟进函数print_header_redirect，在core/print_api.php中：
就是一个简单的header函数，怎么会不干活呢？于是在header函数前面加上die(‘test’);，刷新页面显示test，又改为在header函数后面加上die(‘test’);，再刷新页面还是只显示test，header都是不工作。按理说我这两种操作方式，哪怕不起作用，总也会有个错误提示吧，但是再次查看errorlog文件，依然空手而归。
一个下午就在反复的检查设置、测试、跟踪代码、查找问题中过去了，还好没有放弃，最终把问题集中到了错误报告上面。我的php环境中错误的显示、保存都已经设置好了，但是无论怎么在这个程序里面添加错误的代码，就是不显示和保存错误（这里的保存指错误信息被存到errorlog文件中）。但是另外建了一个简单的测试文件，错误也能显示和保存，header还能够正常的工作。这不是出鬼了么，同样的apache，不同的虚拟目录，就能够有这么大的差别？
继续查找。。。直到吃过晚饭之后，终于发现，在core/error_api.php中，有一句：
后面还有function error_handler，并且这个文件是一大堆被包含文件之一。原来，mantis使用error_handler函数接管了php的错误处理，怪不得什么错误信息都不显示呢。现在，注释掉这一句，错误信息就能够显示了，并且header也能够正常工作了。但是把注释去掉，就又不行了，没办法，就先暂时用系统自带的错误处理功能吧，现在用的mantis 0.19.2版本是老了些，需要升级了，等升级完应该就没事了。
总结：在调试php程序的时候，错误报告对我们是十分有用的，但是在程序明显出错而又看不见错误的时候，别忘了有可能是程序使用set_error_handler函数接管了错误的处理，错误就不会显示和写入errorlog文件了。同样还有set_output_handler接管输出（输出过滤）等类似函数。