背景

前面都是讲解程序未开启优化时的问题定位。当程序未开启优化时，通过‘local’，‘watch','kv' 的参数信息都是正确的，所以很容易可以通过变量的内容确定问题的原因。

但是如果开启了程序优化功能，那么编译器会优化代码的结构，windbg还是按照原来的方法来解析变量，那么大多情况会出现不正确的，比如最重要的this指针，未优化时都是固定在ecx寄存器中，但是开启了优化后就需要自己来查找对应的this地址。

dump信息

下载链接：链接：https://pan.baidu.com/s/1nQOksK2QLUZsQsl7PhgDCw
提取码：4c1o

c/c++的调用约定

C 语言： __cdecl、__stdcall、__fastcall、naked、__pascal。

C++ 语言： __cdecl、__stdcall、__fastcall、naked、__pascal、__thiscall，比 C 语言多出一种 __thiscall 调用方式。

thiscall 调用方式是唯一一种不能显示指定的修饰符。它是C++类成员函数缺省的调用方式。由于成员函数调用还有一个this指针，因此必须用这种特殊的调用方式。

thiscall调用方式意味着：

（1）参数从右向左压入栈。

（2）如果参数个数确定，this指针通过ecx传递给被调用者；如果参数个数不确定，this指针在所有参数压入栈后被压入栈。参数个数不定的，由调用者清理堆栈，否则由函数自己清理堆栈。

可以看到，对于参数个数固定的情况，它类似于stdcall，不定时则类似于cdecl。

分析dump

下载指定的dump，并使用windbg打开，加载好符号文件。
输入命令：".ecxr" ,显示异常上下文：

0:043> .ecxr
eax=0000ffff ebx=00435a18 ecx=04921dc4 edx=060de888 esi=0d7ed468 edi=00000001
eip=00b9d4e7 esp=070efde8 ebp=070efdf4 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
xzmoSvr!CCommonBaseServer::DealApplyBaseWelfare+0x37:
00b9d4e7 ff30            push    dword ptr [eax]      ds:002b:0000ffff=????????
0:043> kv
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child              
070efdf4 00bf54dc 00435f8c 070efe74 0c8bc458 xzmoSvr!CCommonBaseServer::DealApplyBaseWelfare+0x37 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\jenkins\workspace\publish_xzmosvr\gamesvr\commonbase\commonbaseserver.cpp @ 218]
070efe88 733dc01d 00000000 76fc49d0 00000000 xzmoSvr!CMainServer::SoapThreadProc+0x29c (FPO: [Non-Fpo]) (CONV: thiscall) [d:\jenkins\workspace\publish_gametplserver2.0\tcgame2.0\trunk\tcgsvr.cpp @ 9565]
070efec0 733dc001 00000000 070efed8 75ad338a msvcr120!_callthreadstartex+0x1b (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376]
070efecc 75ad338a 04981c78 070eff18 77b89f72 msvcr120!_threadstartex+0x7c (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354]
070efed8 77b89f72 04981c78 75257f9b 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
070eff18 77b89f45 733dbfb4 04981c78 ffffffff ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
070eff30 00000000 733dbfb4 04981c78 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

大致可以猜测是访问非法指针导致的异常。
然后查看代码：

BOOL CCommonBaseServer::DealApplyBaseWelfareEx(LPSOAP_SERVICE pSoapService, IXYSoapClientPtr& pSoapClient, LPCONTEXT_HEAD lpContext, LPREQUEST lpRequest)
{
    BOOL bResult = __super::DealApplyBaseWelfare(pSoapService, pSoapClient, lpContext, lpRequest);
    LPAPPLY_BASEWELFARE_EX lpApplyWelfare = (LPAPPLY_BASEWELFARE_EX)lpRequest->pDataPtr;

    if (bResult && lpApplyWelfare && 0 <= lpApplyWelfare->nSoapReturn)
    {
        if (m_pDataStats)
        {
            m_pDataStats->datastats_onapplywelfare(lpApplyWelfare->nRoomID, lpApplyWelfare->nUserID); ---------> 这行出现问题
        }
    }

    return bResult;
}

并查看异常期间的参数信息：

image

刚开始主程序分析就以为是m_pDataStats = NULL 导致崩溃，原因可能是多线程导致，接着就开始review代码。 但是reivew之后发现m_pDataStats是不能为NULL的（除非进程关闭），然后又是一阵思考、联想、分析........ 无果。
接着猜测是否是踩内存导致（这个review代码难度就有点大了).........

但实际这个dump发生异常的原因不是因为m_pDataStats = NULL导致，而是某个指针的值=0x0000ffff导致，这个在dump中有明确说明：

xzmoSvr!CCommonBaseServer::DealApplyBaseWelfare+0x37:
00b9d4e7 ff30            push    dword ptr [eax]      ds:002b:0000ffff=????????

ds:002b::0000ffff 在访问0000ffff地址时发生异常！！！！！！

但为何看this指针中的m_pDataStats 明明是 NULL啊？ 这就是代码开启优化的原因导致this指针不正确。

如何找到正确的this指针地址呢？通过汇编代码，看优化后的入参方式.使用命令“alt+7”可以打开汇编代码：
函数原型：

BOOL CCommonBaseServer::DealApplyBaseWelfareEx(LPSOAP_SERVICE pSoapService, IXYSoapClientPtr& pSoapClient, LPCONTEXT_HEAD lpContext, LPREQUEST lpRequest)

汇编代码：

xzmoSvr!CCommonBaseServer::DealApplyBaseWelfare:
00b9d4b0 55              push    ebp
00b9d4b1 8bec            mov     ebp,esp
00b9d4b3 53              push    ebx
00b9d4b4 56              push    esi
00b9d4b5 8b7514          mov     esi,dword ptr [ebp+14h]
00b9d4b8 8bd9            mov     ebx,ecx
00b9d4ba 57              push    edi
00b9d4bb 56              push    esi
00b9d4bc ff7510          push    dword ptr [ebp+10h]
00b9d4bf ff750c          push    dword ptr [ebp+0Ch]
00b9d4c2 ff7508          push    dword ptr [ebp+8]

可以看到ecx的地址被移到了ebx中，通过之前异常的寄存器信息可以看到ebx的值

0:043> .ecxr
eax=0000ffff ebx=00435a18 ecx=04921dc4 edx=060de888 esi=0d7ed468 edi=00000001
eip=00b9d4e7 esp=070efde8 ebp=070efdf4 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
xzmoSvr!CCommonBaseServer::DealApplyBaseWelfare+0x37:
00b9d4e7 ff30            push    dword ptr [eax]      ds:002b:0000ffff=????????

ebx=00435a18， 使用'watch'查看内容：

image

可以确定m_pDataStats 不仅指针有效，而且里面的内容也是正确的。所以异常并不是m_pDataStats异常导致。

那么问题就是lpApplyWelfare 这个指针导致。 这时候查看入参lpRequest 内容

image

pDataPtr=0x0000ffff和dump提示的异常指针内容相符，所以可以确定是这个指针导致的。

所以重新对lpRequest进行代码review，发现问题的本质原因：
__super::DealApplyBaseWelfare(pSoapService, pSoapClient, lpContext, lpRequest);
在执行过程中，会将lpRequest 指针post到B线程中执行，而B线程是会释放lpRequest指针的。

所以在低概率情况下，会出现多线程崩溃问题。

修改方式：先copy内存到局部变量，再执行super逻辑。

结论

因为开启了代码优化，导致一开始在分析dump时走向了错误的道路，浪费了时间。在碰到开启代码优化时，查找正确的指针就变的有点困难。

所以我不是很建议新上线的服务开启代码优化，反而增加了问题定位的难度。