我事先道歉,我不能把这个问题更好地归类,但行为是令人费解的程度,我不知道问题可能来自哪里。与另一个开发人员一起,我们试图修复这个错误,因为几个小时,但运气不好。我们不知道问题是否可能源于数据库或PHP(很明显,当那两个人试图交流时,出了问题)。我们希望也许有人有类似的经历,至少能给我们指明一些方向。
这似乎更多的是一个基础设施问题,而不是一个与代码有关的问题,但谁知道呢。
**系统:****CentOS 7 VPS,PHP-FPM 8.1,Symfony 6.0.11,玛丽亚数据库10.2.38
**重要提示:**Symfony设置为dev
环境时一切正常。仅在切换到prod
时出现问题。
Symfony的FormType中有违规代码(请求生命周期中的其他代码似乎无关紧要,删除下面的代码可以完全解决问题,PHP和MariaDB之间的通信似乎可以与所有其他查询正常工作)。
$builder
->add('type', EntityType::class, [
'class' => Property::class,
'choice_label' => 'name',
'query_builder' => function (EntityRepository $er) {
return $er->createQueryBuilder('p')
->orderBy('p.name', 'ASC');
}
])
;
浏览器输出:
- 503服务不可用
由于维护停机或容量问题,服务器暂时无法为您的请求提供服务。请稍后再试。*
服务器日志:
- AH 01067:无法读取FastCGI标头
(104)对等方重置连接:[客户端修订版-IP:53320] AH 01075:将请求分派到以下对象时出错:*
PHP日志:
- 警告:[池管理员]子级1770在启动后1.360270秒后在信号11(SIGSEGV)上退出 *
数据库日志: - [警告]已中止与数据库的连接2787505:“已删除”用户:'已删除'主机:'localhost'(读取通信数据包时出错)*
为了确保安全,我们还尝试了 - 重新启动整个VPS
- 通过rm -r var/cache硬删除Symfony缓存
- 禁用OPcache(一些Google搜索提示了这种关系)
**让我怀疑自己是否理智的部分:**当我从上面的代码中删除整个orderBy
子句时,它开始工作。更令人困惑的是,当我将orderBy('p.name', 'ASC')
改为orderBy('p.name', 'DESC')
时,它也开始工作(原文如此!)。当我将p.name
改为其他有效属性但仍使用ASC
排序时,它不工作。当在这种情况下,我将ASC
改为DESC
时,它工作!
2条答案
按热度按时间vktxenjb1#
在创建了一些模拟测试过程并进一步分析了这些过程生成的核心转储文件之后,我们偶然发现了类似于以下内容的内容
程序终止,信号11,分段故障。
文件名:/usr/local/lib/ioncube/ioncube_example.com中的第0个loader_lin_8.1.so
最新版本的ionCube Loader于8月12日发布:https://www.ioncube.com/loaders.php,似乎是在8月14日自动部署到我们的VPS上的,这正是这些奇怪的错误开始弹出的时间。因此,我们禁用了ionCube Loader扩展,我们所有的PHP脚本再次正常工作。
虽然这并不能精确地指出导致PHP因分段错误而死亡的代码行,但它至少指出了这样一个事实,即ionCube Loader 12.0.1与PHP 8.1结合使用可能会导致SIGSEGV错误。因为大多数脚本工作正常,只有一些脚本在非常奇怪的情况下死亡(正如我最初的帖子所描述的)。但是在所有这些情况下,硬崩溃都是由ionCube Loader 12.0.1的存在触发的,它的开发人员应该是那些更深入研究这个问题的人(我会确保提交正确的崩溃报告)。
在此留下此答案,以防有人遇到类似问题。
6l7fqoea2#
我刚刚遇到了这个完全相同的问题。
PHP版本:8.1.10 Symfony公司:6.0.8条令/dbal(来自 composer 锁定):3.3.6 ionCube装载器:12.0.1
我也遇到了同样的结果。如果我把它从“ASC”改为“DESC”,它就能正常工作。这个问题特别发生在按“ASC”排序时。在我的例子中,我使用的是“addOrderBy”方法。