当前位置： 文江博客话题详情

在堆栈中找不到函数（具有溢出语句）

发布于 2024-11-09 05:53:55 字数 4715 浏览 0 评论 0原文

如果这个问题已经被问过很多次了，但我已经被困在这个问题上有一段时间了，请原谅。
这是具有堆栈溢出代码的函数。在调试时，当我刚刚进入函数时，我可以看到堆栈上的函数。但是当我进一步进入函数时，就会发生溢出，然后我在堆栈上看不到函数名称。

void CCrashMeDlg::OnBnClicked_StackOverflow()
{
    int a = 10;
    a = a+10;
    BYTE bTemp[OneKilo * 1024];    
    bTemp[0] = 0;
}

我的问题是：

  1. 为什么一旦发生溢出，函数就会脱离堆栈。 （我可以看到其他功能）。

  2. 如果我不知道代码或者代码非常大，我如何查明发生溢出的函数？

这是发生溢出后的堆栈。

0034f318 0129d640 CrashMe!_chkstk+0x27 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm @ 99]

0034f328 0129d84f CrashMe!_AfxDispatchCmdMsg+0x45 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 82]

0034f358 01293abe CrashMe!CCmdTarget::OnCmdMsg+0x11c [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 381]

0034f37c 0129a651 CrashMe!CDialog::OnCmdMsg+0x1d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 87]

0034f3cc 0129b2d3 CrashMe!CWnd::OnCommand+0x92 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2675]

0034f488 01295c91 CrashMe!CWnd::OnWndMsg+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2081]

0034f4a8 01299673 CrashMe!CWnd::WindowProc+0x24 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2067]

0034f51c 01299702 CrashMe!AfxCallWndProc+0xac [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 248]

0034f53c 75cc62fa CrashMe!AfxWndProc+0x36 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 410]

0034f568 75cc6d3a USER32!InternalCallWinProc+0x23 [d:\w7rtm\windows\core\ntuser\client\i386\callproc.asm @ 106]

0034f5e0 75cc965e USER32!UserCallWinProcCheckWow+0x109 [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 163]

0034f624 75cc96c5 USER32!SendMessageWorker+0x581 [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 717]

0034f648 71bc4601 USER32!SendMessageW+0x7f [d:\w7rtm\windows\core\ntuser\client\cltxt.h @ 795]

0034f668 71bc4663 COMCTL32!Button_NotifyParent+0x3d [d:\w7rtm\shell\comctl32\v6\button.cpp @ 2322]

0034f684 71bc44ed COMCTL32!Button_ReleaseCapture+0x113 [d:\w7rtm\shell\comctl32\v6\button.cpp @ 2424]

0034f6e4 75cc62fa COMCTL32!Button_WndProc+0xa18 [d:\w7rtm\shell\comctl32\v6\button.cpp @ 4934]

0034f710 75cc6d3a USER32!InternalCallWinProc+0x23 [d:\w7rtm\windows\core\ntuser\client\i386\callproc.asm @ 106]

0034f788 75cc77c4 USER32!UserCallWinProcCheckWow+0x109 [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 163]

0034f7e8 75cc788a USER32!DispatchMessageWorker+0x3bc [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 2591]

0034f7f8 75cec81f USER32!DispatchMessageW+0xf [d:\w7rtm\windows\core\ntuser\client\cltxt.h @ 999]

0034f824 0129c82e USER32!IsDialogMessageW+0x5f6 [d:\w7rtm\windows\core\ntuser\client\dlgmgr2.c @ 659]

0034f838 01296ba0 CrashMe!CWnd::IsDialogMessageW+0x32 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 197]

0034f844 01293a9b CrashMe!CWnd::PreTranslateInput+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4659]

0034f858 01299144 CrashMe!CDialog::PreTranslateMessage+0xa3 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 81]

0034f86c 012a06f2 CrashMe!CWnd::WalkPreTranslateTree+0x23 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3258]

0034f884 012a08dd CrashMe!AfxInternalPreTranslateMessage+0x41 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]

0034f890 012a073d CrashMe!CWinThread::PreTranslateMessage+0xd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]

0034f89c 012a092d CrashMe!AfxPreTranslateMessage+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]

0034f8ac 0129818e CrashMe!AfxInternalPumpMessage+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]

0034f8d4 012941d6 CrashMe!CWnd::RunModalLoop+0xc5 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4714]

0034f920 01453a9f CrashMe!CDialog::DoModal+0x130 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 638]

0034fa20 01453987 CrashMe!CCrashMeApp::InitInstance+0x8f [d:\docs\windbg\crashme\crashme\crashme.cpp @ 64]

0034fa34 01424bc6 CrashMe!AfxWinMain+0x48 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]

0034fac4 76d533ca CrashMe!__tmainCRTStartup+0x11a [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 275]

0034fad0 77ce9ed2 kernel32!BaseThreadInitThunk+0xe [d:\w7rtm\base\win32\client\thread.c @ 65]

0034fb10 77ce9ea5 ntdll!__RtlUserThreadStart+0x70 [d:\w7rtm\minkernel\ntos\rtl\rtlexec.c @ 3188]

0034fb28 00000000 ntdll!_RtlUserThreadStart+0x1b [d:\w7rtm\minkernel\ntos\rtl\rtlexec.c @ 3116]

原文

Please excuse me if this question has been asked a number of times but I have been stuck on this for some time.
here is the function that has stack overflow code. on debugging when I have just entered into the function I can see the function on the stack.. but the moment I step further into function, the overflow happens and then I can't see the function name on the stack.

void CCrashMeDlg::OnBnClicked_StackOverflow()
{
    int a = 10;
    a = a+10;
    BYTE bTemp[OneKilo * 1024];    
    bTemp[0] = 0;
}

My questions are :

  1. Why the function is going off the stack once overflow happens. (I can see other functions).

  2. if I dont know the code or if the code is very big how wud I pinpoint the function where overflow is happening?

here is the stack after overflow has happened.

0034f318 0129d640 CrashMe!_chkstk+0x27 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm @ 99]

0034f328 0129d84f CrashMe!_AfxDispatchCmdMsg+0x45 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 82]

0034f358 01293abe CrashMe!CCmdTarget::OnCmdMsg+0x11c [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 381]

0034f37c 0129a651 CrashMe!CDialog::OnCmdMsg+0x1d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 87]

0034f3cc 0129b2d3 CrashMe!CWnd::OnCommand+0x92 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2675]

0034f488 01295c91 CrashMe!CWnd::OnWndMsg+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2081]

0034f4a8 01299673 CrashMe!CWnd::WindowProc+0x24 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2067]

0034f51c 01299702 CrashMe!AfxCallWndProc+0xac [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 248]

0034f53c 75cc62fa CrashMe!AfxWndProc+0x36 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 410]

0034f568 75cc6d3a USER32!InternalCallWinProc+0x23 [d:\w7rtm\windows\core\ntuser\client\i386\callproc.asm @ 106]

0034f5e0 75cc965e USER32!UserCallWinProcCheckWow+0x109 [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 163]

0034f624 75cc96c5 USER32!SendMessageWorker+0x581 [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 717]

0034f648 71bc4601 USER32!SendMessageW+0x7f [d:\w7rtm\windows\core\ntuser\client\cltxt.h @ 795]

0034f668 71bc4663 COMCTL32!Button_NotifyParent+0x3d [d:\w7rtm\shell\comctl32\v6\button.cpp @ 2322]

0034f684 71bc44ed COMCTL32!Button_ReleaseCapture+0x113 [d:\w7rtm\shell\comctl32\v6\button.cpp @ 2424]

0034f6e4 75cc62fa COMCTL32!Button_WndProc+0xa18 [d:\w7rtm\shell\comctl32\v6\button.cpp @ 4934]

0034f710 75cc6d3a USER32!InternalCallWinProc+0x23 [d:\w7rtm\windows\core\ntuser\client\i386\callproc.asm @ 106]

0034f788 75cc77c4 USER32!UserCallWinProcCheckWow+0x109 [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 163]

0034f7e8 75cc788a USER32!DispatchMessageWorker+0x3bc [d:\w7rtm\windows\core\ntuser\client\clmsg.c @ 2591]

0034f7f8 75cec81f USER32!DispatchMessageW+0xf [d:\w7rtm\windows\core\ntuser\client\cltxt.h @ 999]

0034f824 0129c82e USER32!IsDialogMessageW+0x5f6 [d:\w7rtm\windows\core\ntuser\client\dlgmgr2.c @ 659]

0034f838 01296ba0 CrashMe!CWnd::IsDialogMessageW+0x32 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 197]

0034f844 01293a9b CrashMe!CWnd::PreTranslateInput+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4659]

0034f858 01299144 CrashMe!CDialog::PreTranslateMessage+0xa3 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 81]

0034f86c 012a06f2 CrashMe!CWnd::WalkPreTranslateTree+0x23 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3258]

0034f884 012a08dd CrashMe!AfxInternalPreTranslateMessage+0x41 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]

0034f890 012a073d CrashMe!CWinThread::PreTranslateMessage+0xd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]

0034f89c 012a092d CrashMe!AfxPreTranslateMessage+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]

0034f8ac 0129818e CrashMe!AfxInternalPumpMessage+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]

0034f8d4 012941d6 CrashMe!CWnd::RunModalLoop+0xc5 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4714]

0034f920 01453a9f CrashMe!CDialog::DoModal+0x130 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 638]

0034fa20 01453987 CrashMe!CCrashMeApp::InitInstance+0x8f [d:\docs\windbg\crashme\crashme\crashme.cpp @ 64]

0034fa34 01424bc6 CrashMe!AfxWinMain+0x48 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]

0034fac4 76d533ca CrashMe!__tmainCRTStartup+0x11a [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 275]

0034fad0 77ce9ed2 kernel32!BaseThreadInitThunk+0xe [d:\w7rtm\base\win32\client\thread.c @ 65]

0034fb10 77ce9ea5 ntdll!__RtlUserThreadStart+0x70 [d:\w7rtm\minkernel\ntos\rtl\rtlexec.c @ 3188]

0034fb28 00000000 ntdll!_RtlUserThreadStart+0x1b [d:\w7rtm\minkernel\ntos\rtl\rtlexec.c @ 3116]

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（3）

浴红衣 2024-11-16 05:53:55

当程序试图分配一个巨大的基于堆栈的变量时，就会发生堆栈溢出。当你第一次进入函数时，程序计数器将进入该函数，但它还不会执行它（包括初始化和堆栈变量分配）。但是，一旦您再次进入，它将使用操作码分配堆栈变量：

sub esp, xxx; //xxx 是堆栈变量的大小

如果 esp-xxx 的结果超出堆栈内存页，则会抛出堆栈溢出。因为当你第二次进入时它就会分配堆栈变量，所以你马上就会知道你在变量声明中犯了一些错误。

解决方案是：

  1. 增加堆栈大小（项目设置->链接器->系统->堆栈大小）
  2. 在堆中分配变量。

当递归调用次数过多时也会出现堆栈溢出。大多数函数都需要在堆栈中进行一些临时存储，如果您尝试分配它太多次，它将超出内存范围。著名的例子是递归调用自身来查找斐波那契数列的函数。当n超过100000~时，通常会（假设堆栈大小为1MB，这是VS的默认大小）导致堆栈溢出。

唯一的解决方案是增加堆栈大小。

Stack overflow will occur when the program tries to allocate a huge stack based variable. When you first step into the function, the program counter will go into the function, but it won't execute it(including the initialization and stack variable allocation) yet. However as soon as you step into once more, it will allocate the stack variables using the opcode:

sub esp, xxx; //xxx is the size of the stack variable

If result of esp-xxx is beyond the stack memory page, it will throw stack overflow. Because it will be allocating the stack variable as soon as you step into for the second time, you'll know right away that you've made some mistake in the variable declaration.

The solution for this would be either:

  1. increase stack size (Project Settings->Linker->System->Stack Size)
  2. allocate variable in heap.

Stack overflow will also occur when you recursive call too many times. Most functions require some temporary storage in stack and If you try to allocate this too many times, it will go beyond the memory. The famous example for this would be the function that recursively calls itself to find fibonacci sequence. When n goes above 100000~, it will generally(assuming stack size is 1MB, which is the default size of VS) cause stack overflow.

The only solution for this would be to increase the stack size.

回复 原文
裸钻 2024-11-16 05:53:55

_chkstk 未建立 ebp 链并正在修改堆栈帧，这可能会导致调试器无法正确展开堆栈。

如果反汇编_chkstk，您可能会发现返回地址的存储位置。在下面的示例中，它位于 ecx 寄存器中。

0:000> u ntdll!_chkstk
ntdll!_chkstk:
778fad68 51              push    ecx
778fad69 8d4c2404        lea     ecx,[esp+4]
778fad6d 2bc8            sub     ecx,eax
778fad6f 1bc0            sbb     eax,eax
778fad71 f7d0            not     eax
778fad73 23c8            and     ecx,eax
778fad75 8bc4            mov     eax,esp
778fad77 2500f0ffff      and     eax,0FFFFF000h
0:000>

_chkstk does not establish an ebp chain and is modifying the stack frame which may cause the debugger to not be able to correctly unwind the stack.

If you disassemble _chkstk you may find where the return address is stored. In the example below it is in the ecx register.

0:000> u ntdll!_chkstk
ntdll!_chkstk:
778fad68 51              push    ecx
778fad69 8d4c2404        lea     ecx,[esp+4]
778fad6d 2bc8            sub     ecx,eax
778fad6f 1bc0            sbb     eax,eax
778fad71 f7d0            not     eax
778fad73 23c8            and     ecx,eax
778fad75 8bc4            mov     eax,esp
778fad77 2500f0ffff      and     eax,0FFFFF000h
0:000>
回复 原文
╭⌒浅淡时光〆 2024-11-16 05:53:55

我猜这是因为以下行在堆栈上分配了很多内存：

 BYTE bTemp[OneKilo * 1024];

尝试在堆上分配数据：

 BYTE *bTemp = new Byte[OneKilo * 1024];

之后不要忘记释放内存

I guess it is because the following line allocates to much memory on stack:

 BYTE bTemp[OneKilo * 1024];

Try allocating your data on the heap:

 BYTE *bTemp = new Byte[OneKilo * 1024];

dont forget to free the memory afterwards

回复 原文
~没有更多了~

关于作者

若相惜即相离

暂无简介

0 文章
0 评论
22 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

烙印

文章 0 评论 0

singlesman

文章 0 评论 0

给自己一个微笑

文章 0 评论 0

独孤求败

文章 0 评论 0

晨钟暮鼓

文章 0 评论 0

我是自愿种绣球花的

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文