DoubleLi

qq: 517712484 wx: ldbgliet

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  4737 随笔 :: 2 文章 :: 542 评论 :: 1615万 阅读
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

问题如题描述,python 运行过程中直接导致python 解释器崩溃(不是异常,直接崩溃),下面简叙一下debug过程:

  1. google查询结果显示这种情况多数是因为Python里的C扩展导致(访问了非法内存区域,可能和C自身内存管理机制有关),而且可以用gdb进行debug(因为Python崩溃,没法用python自身的debug机制,定位到出错的位置),gdb就输出一个出错的内存地址,楼主没想深究,所以这作为一个保留debug手段,继续SEARCH,看有没有更直接的方案。
    因为错误是内存越界访问,想到代码里楼主手动增加了python的可递归次数
sys.setrecursionlimit(100000)
  1. 果然,把值调小以后,没有崩溃,而是报了异常(RuntimeError: maximum recursion depth exceeded),看来有可能是这里出了问题,所以SEARCH “sys.setrecursionlimit 导致 Segmentation fault (core dumped)”,搜到这篇https://bytes.com/topic/python/answers/36935-core-dump-increased-recursionlimit,猜测是被linux本身的stack size给limit了,于是:When I change the limit to “unlimited” (ulimit -S -s unlimited),运行:
ulimit -a

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62876
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 62876
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

stack size果然有限制,改成没有限制

ulimit -S -s unlimited
改完以后

stack size (kbytes, -s) unlimited

OK, 至此问题解决

 
posted on   DoubleLi  阅读(370)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?
· 展开说说关于C#中ORM框架的用法!
点击右上角即可分享
微信分享提示