Python主进程hang住的两个原因

  • 时间:
  • 浏览:2
  • 来源:神彩UU直播_彩神UU直播官方

定位步骤:

pstack 主系统守护进程,查看python语言源码的c调用栈,追踪主系统守护进程(图中系统守护进程1)的各个函数调用栈的python源码,猜测是阻塞在threading._shutdown最好的办法上,修改threading模块源码,并加上日志,定位我我确实阻塞在_exitFunc的循环join thread上。



系统守护进程2的表现是不断创建不断退出,为threading.start入口加上打印traceback,最终定位在五个 多多 模块的心跳计时器。调大心跳周期,观察步骤1中的系统守护进程id,选择是心跳计时器系统守护进程。注: approach 2中可用ctrl-c构造异常,构造hang住的清况 。

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/feilengcui008/article/details/52831354

最近使用Python遇到五个 多多 非常不好定位的问题报告 ,表现都不 Python主系统守护进程hang住。最终定位出五个 多多 是subprocess模块的问题报告 ,五个 多多 是threading.Timer系统守护进程的问题报告 。

Python的subprocess比较强大,基本可不也能替换os.system、os.popen、commands.getstatusoutput的功能,但会 在使用的过程中需要注意参数stdin/stdout/stderr使用subprocess.PIPE的清况 ,可能性管道通常会有默认的buffer size(Linux x86_64下实测是64K,这里有个问题报告 io.DEFAULT_BUFFER_SIZE是8K,而ulimit -a的pipe size为512 * 8 = 4K?),父系统守护进程可能性不使用communicate消耗掉子系统守护进程write pipe(stdout/stderr)中的数据,直接进入wait,此时子系统守护进程可能性阻塞在了pipe的写上,从而愿因分析父子系统守护进程都hang住。下面是测试代码。

重现poc

另外,在subprocess模块源码中还注释说明了另外并都不 可能性fork -> 子系统守护进程gc -> exec愿因分析的系统守护进程hang住,全版信息可不也能阅读subprocess模块源码。