当前位置: 技术问答>linux和unix
linux下的诡异coredump问题
来源: 互联网 发布时间:2017-03-02
本文导语: 在linux下发现诡异coredump问题,经分析原因应当是全局静态对象被破坏了导致的. 这样的问题一般都是由内存越界导致的,但使用purify跑,除了一个UMR之外没有发现其他问题, 发生问题的时候就是在coredump所在位置的内存段...
在linux下发现诡异coredump问题,经分析原因应当是全局静态对象被破坏了导致的.
这样的问题一般都是由内存越界导致的,但使用purify跑,除了一个UMR之外没有发现其他问题,
发生问题的时候就是在coredump所在位置的内存段错误,始终找不出来是哪个部分导致的内存越界.
百思不得其解
各位大侠有没什么其他思路或者方法手段来定位问题的,望不吝赐教.
这样的问题一般都是由内存越界导致的,但使用purify跑,除了一个UMR之外没有发现其他问题,
发生问题的时候就是在coredump所在位置的内存段错误,始终找不出来是哪个部分导致的内存越界.
百思不得其解
各位大侠有没什么其他思路或者方法手段来定位问题的,望不吝赐教.
|
这是非常头痛的越界"漂移"的问题。
除了写代码时非常小心外,似乎没有很特别的避免的办法。
既然已经知道一个map会被覆盖掉,还是有希望比较快找到问题的,建议:
(1) 因为map是一个全局变量,因此重点检查所有全局变量的初始化、赋值、释放等操作是否越界。
(2) 在所有被怀疑的代码段中,加入跟踪Map对象地址以及其中某个固定成员的值,看看它们的值在何位置发生异常改变,并逐步缩小代码的范围。
其中第二点是我常用来解决类似问题的笨办法。
期望有更巧妙的方法。
除了写代码时非常小心外,似乎没有很特别的避免的办法。
既然已经知道一个map会被覆盖掉,还是有希望比较快找到问题的,建议:
(1) 因为map是一个全局变量,因此重点检查所有全局变量的初始化、赋值、释放等操作是否越界。
(2) 在所有被怀疑的代码段中,加入跟踪Map对象地址以及其中某个固定成员的值,看看它们的值在何位置发生异常改变,并逐步缩小代码的范围。
其中第二点是我常用来解决类似问题的笨办法。
期望有更巧妙的方法。
|
如果全局静态对象被破坏,就是数据段的数据被破坏,这就不像被堆破坏,因为堆是从低往高增长, 而栈是是从高往低增长,
代码中是否存在在栈上分配一个特别特别大的数据(比如特别大的数组)导致了栈溢出?
栈
堆
数据段
文段
代码中是否存在在栈上分配一个特别特别大的数据(比如特别大的数组)导致了栈溢出?
栈
堆
数据段
文段
|
贴代码?