- 主题:内存覆盖问题都是咋定位的？
有啥好工具办法么。我这只能瞎猜。
--
FROM 117.133.52.*
这些我都没用过。因为平时也不总出这种问题。但隔很久出一个就很麻烦。看来得研究一下这俩工具。
【 在 z16166 的大作中提到: 】
: valgrind、sanitizer之类的。在分配的内存的上面、下面加guard。
: 如果这个搞不定，那只能人工了
--
FROM 117.133.52.*
就是崩溃。变量地址被覆盖。不过是linux下面的程序。
【 在 DoorWay 的大作中提到: 】
: 你怎么知道有内存覆盖问题的？崩溃？
: windows gflags.exe /page，查下手册，挺好用。
: 但是你得先分析确定。
: ...................
--
FROM 117.133.52.*
昨天简单试了一下 valgrind，程序不能正常启动。初始化有一行失败，不加valgrind正常。
这个程序是个稍微大型的长时间后台服务。总有个函数入参被覆盖，而且需要跑很久才能碰上。用watch貌似也不太行，我要试试再说
【 在 jinggangshan 的大作中提到: 】
: gdb的watch变量功能 如果好复现并且可以用gdb启动程序运行的话
: :就是崩溃。变量地址被覆盖。不过是linux下面的程序。
: - 来自 水木社区APP v3.5.7
--
FROM 125.33.34.*
这个还没来得及试
【 在 gunix 的大作中提到: 】
: address sanitizer呀。
--
FROM 125.33.34.*
coredump也看不出来哪儿益处的。val目前启动不正常。还不知道为啥
【 在 DoorWay 的大作中提到: 】
: 1 打开STL的越界检查
: g++ -D_GLIBCXX_DEBUG -o output_file input_file.cpp
: 2 调试dump 文件. ，确定文件和函数
: ...................
--
FROM 125.33.34.*
找bug也需要灵感的
【 在 AGust2022 的大作中提到: 】
: 去写诗吧
:
--
FROM 125.33.34.*
Linux
【 在 AGust2022 的大作中提到: 】
: 在什么环境下覆盖的？
:
--
FROM 125.33.34.*
gdb可以启动。但是看不出来啥
【 在 jinggangshan 的大作中提到: 】
: 也可以尝试启动稳定运行后 再用gdb attach上去watch
: :昨天简单试了一下 valgrind，程序不能正常启动。初始化有一行失败，不加valgrind正常。:这个程序是个稍微大型
: - 来自 水木社区APP v3.5.7
--
FROM 125.33.34.*
几十万行，大是指占的内存大。而且都是分配的大页内存。两百来g。
现在不确定是内存导致起不来。没次都失败在设置程序文件具柄限制那行。不知道什么原因。我昨天简单试了一下，等下周有空研究一下。
【 在 DoorWay 的大作中提到: 】
: 不能启动是不是内存占太大了。gflags.exe有选项只监控某个dll。
: 大型？多大，百万行？一般是平台大，模块小。
: 如果很难复现，那还不到改的时机，先稳定复现吧。不然改了怎么证明改好了？
--
FROM 125.33.34.*