[已解决]Linux平台程序运行莫名崩溃（怀疑是内存越界导致），求助大神解惑！

breakthrough

问题现象：现象的话参见图片
堆栈信息（来源gdb 解析core文件）
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f824574518b in raise () from /lib/x86_64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x7f82414bda80 (LWP 26702))]
b(gdb) bt
#0  0x00007f824574518b in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f8245724859 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f824578f3ee in  () at /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f824579747c in  () at /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f8245797af7 in  () at /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007f824579a773 in  () at /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007f824579c419 in malloc () at /lib/x86_64-linux-gnu/libc.so.6
#7  0x00007f824599dc29 in operator new(unsigned long) ()
    at /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007f824808f252 in CreateEvent(tagSECURITY_ATTRIBUTES*, int, int, char const*) (lpEventAttributes=0x0, bManualReset=1, bInitialState=0, lpName=0x0)
    at WinEvent.cpp:29
#9  0x00007f82477f8b39 in CSCNamedPipeClt::SendMsgAndReceive(void const*, unsigned long, void**, unsigned long*, int) (this=
    0x56166d2a1a00, pBuf=0x56166df36000, bufSize=44, ppOutBuf=0x7ffcaca85e98, pOutBufSize=0x7ffcaca85ea0, nTimeOut=60000) at SCNamedPipeClt.cpp:303
#10 0x00007f82477e844d in CSCNamedPipeCltMgr::SendAndReceive(unsigned long, void const*, unsigned long, void**, unsigned long*, int)
    (this=0x7f8247833c40 <g_cltMgr>, cltID=0, pBuf=0x56166df36000, size=44, ppOutBuf=0x7ffcaca85e98, pOutBufSize=0x7ffcaca85ea0, nTimeOut=60000)
    at SCNamedPipeMgr.cpp:254
#11 0x00007f82477e2c5b in SCNPClt_SendAndReceive(unsigned long, void const*, unsigned long, void**, unsigned long*, int)
--Type <RET> for more, q to quit, c to continue without paging--
    (cltID=0, pBuf=0x56166df36000, bufSize=44, ppOutBuf=0x7ffcaca85e98, pOutBufSize=0x7ffcaca85ea0, nTimeOut=60000) at SCNamedPipe.cpp:45
#12 0x00007f8243e958a3 in CNPClt::SendAndReceive(void const*, unsigned int, void**, unsigned long*)
    (this=0x56166d28ab40, pBuf=0x56166df36000, bufSize=44, ppOutBuf=0x7ffcaca85e98, pOutBufSize=0x7ffcaca85ea0) at NPClt.cpp:71

按照堆栈的信息找到对应的代码，就是一个普通的new操作
EVENT* pEvent= new EVENT()；

EVENT定义如下：
typedef struct  tagEvent{

最佳答案

月排行榜 / 总排行榜

jackz007

2022-10-20 19:57:02

breakthrough 发表于 2022-10-21 10:40
这条语句单独测试没有问题的，之前就已经做过测试了。整体进程上，存在堆破坏的地方，但一直无法确认破坏 ...

          如果连自己都不知道应该怀疑哪些环节，那这个问题恐怕就没有解决的可能了。

          一般灾难性的后果不应该出在内存分配过程本身，而是应该出在通过野指针对内存的访问。当通过 new 语句分配内存不成功的时候，拿到的指针值就是 NULL，如果不加判断就投入使用，就会直接导致灾难的发生，我想，如果给每一个指针都添加上使用前判断，那么，应该就可以杜绝绝大多数程序崩溃的事情发生。

跳转到最佳答案楼层

jackz007

breakthrough 发表于 2022-10-21 10:40
这条语句单独测试没有问题的，之前就已经做过测试了。整体进程上，存在堆破坏的地方，但一直无法确认破坏 ...

          如果连自己都不知道应该怀疑哪些环节，那这个问题恐怕就没有解决的可能了。

          一般灾难性的后果不应该出在内存分配过程本身，而是应该出在通过野指针对内存的访问。当通过 new 语句分配内存不成功的时候，拿到的指针值就是 NULL，如果不加判断就投入使用，就会直接导致灾难的发生，我想，如果给每一个指针都添加上使用前判断，那么，应该就可以杜绝绝大多数程序崩溃的事情发生。

breakthrough

问题限长，补充数据结构
typedef struct tageEvent{
        struct  tagHANDLE         h;
        sem_t*                         p_bin_sem;
        BOOL                          bManalReset;
        BOOL                          bNameEvent;
        pthread_rwlock_t         rwCs;
        char                                 szEventName[260];
} EVENT;

jackz007

breakthrough 发表于 2022-10-20 19:59
问题限长，补充数据结构
typedef struct tageEvent{
        struct  tagHANDLE         h;

EVENT* pEvent= new EVENT()；

        如果有这个怀疑，那就不妨安排一个循环，专门测试这条问题语句，打印循环计数，看看究竟会不会重现奔溃效果，以及究竟多少次会导致奔溃。

breakthrough

jackz007 发表于 2022-10-20 20:53
如果有这个怀疑，那就不妨安排一个循环，专门测试这条问题语句，打印循环计数，看看究竟会不 ...

这条语句单独测试没有问题的，之前就已经做过测试了。整体进程上，存在堆破坏的地方，但一直无法确认破坏第一现场

breakthrough

jackz007 发表于 2022-10-21 18:35
如果连自己都不知道应该怀疑哪些环节，那这个问题恐怕就没有解决的可能了。

          一 ...

不好意思，时间有点长了，回复的有点晚。不是这样的，正常的new操作失败的情况下回返回NULL或者其他形式的返回，我在项目中碰到的情况是，new出不来了，直接内部崩了，明显的是内存结构崩溃了，后来通过屏蔽代码发现了问题的原因，这玩意代码不是我写的。不过还是谢谢你的解答