-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
swoole5.0.1 php8.1/8.0.23 使用table incr/set 出现段错误。附有coredump分析 #4954
Comments
这个看起来像是地址问题,gdb的时候输入f 0进入alloc函数,打印一下slice看看。 |
还需要更详细的信息吗,我会及时补充上来 |
slice在这里是个空指针,所以段错误了。我看看是为啥。 |
|
可以gdb之后, f 0 进去alloc看看impl->head是不是空指针吗 |
(gdb) p impl |
谢谢 |
应该的。目前的现状是。我曾经部署过两个版本的swoole服务在k8s上。swoole的版本都是5.0.1,但php的版本曾经打过8.1和8.0.23的镜像。 8.1的gdb分析是这样的:
8.0.23 (当前部署的版本)
两者的报错还不太一样。 @ @NathanFreeman 请问这两者我需要部署哪个版本更利于你们分析? |
还要看看gdb之后, f 0 进入alloc函数,执行完 |
|
谢谢 |
@wuyiwai 是否有其他进程执行了 另外日志中有 |
|
还发现了一些别的coredump分析
|
@wuyiwai 上面的 core 信息无效了,堆栈已破坏,无法分析问题。可以关闭 grpc 试试,另外在 gdb core 中可以使用 info threads 看看是否有其他的线程正在执行什么操作。 status 255 比较可以,包括 php error_log 、swoole log_file 都需要看一下,是否存在 fatal error 另外对 table 的操作只有 set、incr、del 这些吗?key 就是类似于 '48142122:5' 这样的格式,请提供一下 table create 时的参数 |
swoole log_file 目前在k8s上设置为false所以没有收集到文件,是配置了日志收集stdout输出的日志,不过去搜了发现有一些新的结果,可以留意下,大概有一下几种:
|
我去看了下 源码里面的 table.cc的lock方法的描述:
不过我没能想到我的代码里有哪些应用场景有可能会触发这些。
|
@matyhtf @NathanFreeman 我还需要提供什么信息以推进该问题的定位吗 |
@matyhtf @NathanFreeman 刚刚我去对比了swoole的版本更新日志,涉及table的有多个迭代,其中一些bug修复提到了修复相关的内存错误,我想到之前应该是有issue或者有什么方式是可以正确的反馈能帮助定位table的问题的。我额外想到一些不知道有没有关系的信息:我之前的服务在4.4.16版本上运行了2年多没有报错,在5.0.1、4.8版本上运行后的core dump里有关于table的错误。以下是关于table的更新的一些列举:
|
@wuyiwai 可能是在hash冲突分配动态内存时发生了 OOM,查看
|
|
@wuyiwai 加一下我的微信,19921030512 方便沟通,需要本地压测试试看能不能重现 |
重新用php 8.1.20 和swoole 5.0.3 部署了还是会有这个情况
最新捕捉的上下文:
9点54分:同时间的业务日志:
相关代码如下:
下面是我的一些额外的猜想:
为了尽可能捕捉报错的信息,我额外打印了一些日志:
更早一些的日志:
这个记录是十分钟记录一次memory信息 .不清楚这个conflict_proportion = 0.2 和table的设置有没有关系 |
Please answer these questions before submitting your issue.
What did you do? If possible, provide a simple script for reproducing the error.
我写了一个swoole的Server,部署在k8s上,在server里使用了table,总的大概预先分配了20g内存给table,程序的主要逻辑是在table中做set和incr操作,在这个过程中发现会使得程序异常,产生coredump。关键代码如下:
以上简单的代码暂时无法稳定复现,但启动服务后,24h内必定产生coredump。只能从coredump日志推出是由于incr导致。由于我incr的入口只有这一处,且上下文没有很特殊的逻辑,所以暂时无法提供稳定复现的php代码。
What did you expect to see?
如果该问题很明确且有解决方案,希望获取解决方案。
如果该问题不清晰或目前没有解决方案,由于目前没有方向进行继续定位,希望可以提供一些方向使得我可以继续进行debug,如果信息不够可以沟通继续补充。
What did you see instead?
目前在程序的stdout日志中,会打印出以下log,属于issue中的段错误类型
下面是php 8.0.23版本下的调试分析
对coredump文件进入gdb调试后的堆栈信息如下:
还有一些其他的core dump,是在php 8.1版本上测的,内容差不多,一起贴上来
What version of Swoole are you using (show your
php --ri swoole
)?What is your machine environment used (show your
uname -a
&php -v
&gcc -v
) ?The text was updated successfully, but these errors were encountered: