- 主题:内存覆盖问题都是咋定位的？
有啥好工具办法么。我这只能瞎猜。
--
FROM 117.133.52.*
valgrind、sanitizer之类的。在分配的内存的上面、下面加guard。
如果这个搞不定，那只能人工了
--
修改:z16166 FROM 123.118.191.*
FROM 123.118.191.*
你怎么知道有内存覆盖问题的？崩溃？
windows gflags.exe /page，查下手册，挺好用。
但是你得先分析确定。
【 在 chunhui 的大作中提到: 】
: 有啥好工具办法么。我这只能瞎猜。
--
FROM 36.45.47.*
这些我都没用过。因为平时也不总出这种问题。但隔很久出一个就很麻烦。看来得研究一下这俩工具。
【 在 z16166 的大作中提到: 】
: valgrind、sanitizer之类的。在分配的内存的上面、下面加guard。
: 如果这个搞不定，那只能人工了
--
FROM 117.133.52.*
就是崩溃。变量地址被覆盖。不过是linux下面的程序。
【 在 DoorWay 的大作中提到: 】
: 你怎么知道有内存覆盖问题的？崩溃？
: windows gflags.exe /page，查下手册，挺好用。
: 但是你得先分析确定。
: ...................
--
FROM 117.133.52.*
gdb的watch变量功能 如果好复现并且可以用gdb启动程序运行的话
【 在 chunhui 的大作中提到: 】
:就是崩溃。变量地址被覆盖。不过是linux下面的程序。
- 来自 水木社区APP v3.5.7
--
FROM 49.77.29.*
address sanitizer呀。
【 在 chunhui 的大作中提到: 】
: 有啥好工具办法么。我这只能瞎猜。
--
FROM 106.125.113.*
1 打开STL的越界检查
g++ -D_GLIBCXX_DEBUG -o output_file input_file.cpp
2 调试dump 文件. ，确定文件和函数
gcore -o 生产dump,
gdb a.exe a.dump
list 查看源码
3 使用gflags.exe类似的工具，在分配的内存前后加上保护字节，运行时检查。
运行很慢。
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./your_program
【 在 chunhui 的大作中提到: 】
: 就是崩溃。变量地址被覆盖。不过是linux下面的程序。
--
FROM 61.185.159.*
一般程序，基本不用new，应该比较好定位。
多线程，另外一回事，不好调试。linux调试器也不如VS。
【 在 DoorWay 的大作中提到: 】
: 1 打开STL的越界检查
: g++ -D_GLIBCXX_DEBUG -o output_file input_file.cpp
: 2 调试dump 文件. ，确定文件和函数
: ...................
--
FROM 61.185.159.*
昨天简单试了一下 valgrind，程序不能正常启动。初始化有一行失败，不加valgrind正常。
这个程序是个稍微大型的长时间后台服务。总有个函数入参被覆盖，而且需要跑很久才能碰上。用watch貌似也不太行，我要试试再说
【 在 jinggangshan 的大作中提到: 】
: gdb的watch变量功能 如果好复现并且可以用gdb启动程序运行的话
: :就是崩溃。变量地址被覆盖。不过是linux下面的程序。
: - 来自 水木社区APP v3.5.7
--
FROM 125.33.34.*