简体   繁体   中英

Call stack of thread is full of the same function calls — curl_inet_ntop()

I'm analyzing a memory dump of a process in WinDbg, specifically the call stack of one of the threads. The output of the call stack is the following:

0:008> kb
RetAddr           : Args to Child                                                           : Call Site
00000000`0089e0d4 : 0369f3dc`0089e0c0 00000001`00000000 ffffffff`0097541c 00000000`0369e494 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 0097541c`00000000 0369e4a4`00000000 00000000`00000000 00000089`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000003`00000000 00000000`00000000 00000017`00000000 00000000`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000000`00000000 00000002`00000000 00000001`0097541c 010669d0`0369e4f8 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00973376`00000000 775b1b47`00973379 01060000`01060000 010dba60`01060000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 775b5bb8`0369e544 0000077f`01060000 010dba68`775b1ace 0000a4b0`000007ff : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 01060000`010dba60 01060054`00000000 0000a4b0`0000a4b0 7757f7f1`0369e598 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000800`01060000 01060000`00000000 00000000`010dba60 000007ff`0111ba70 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 01060000`000024af 00000000`010dba60 00000000`8b0024af 010ce9e0`01060000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 010dba60`00000000 00000003`01060000 00000000`00000000 0000000a`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000003`00000000 00000000`00000000 0000005f`00000000 00000003`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000000`00000000 00000030`00000000 00000003`00000000 00000000`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000001`00000000 00000001`00000000 00000000`00000000 00977ae4`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000001`0369e640 00000000`00000000 017897f8`00000000 0369e644`00000000 : TestService!Curl_inet_ntop+0x714
00000000`0089e0d4 : 00000000`ffffffff 00000000`775b1e12 77565191`0369f2f4 fffffffe`7837cb7b : TestService!Curl_inet_ntop+0x714

This output is only a portion of the entire stack, which contains a hundred more of the same call.

Could someone explain what is happening in this call stack? Is this thread just repeatedly calling the same function, curl_inet_ntop()?

Not actually an answer, but too long for comment. Try to da a kc 9999 To see if there is some different calls further up on the stack. If that fails, da a !teb Check if @rsp is between StackBase and StackLimit,

0:000> !teb
TEB at 000007fffffde000
    ExceptionList:        0000000000000000
    StackBase:            0000000000130000
    StackLimit:           000000000010e000

0:000> r @rsp
rsp=000000000012d7b8

Now you can do a

0:000> dqs @rsp 0000000000130000  <- StackBase

Now you can try to figure potential return addresses , ub is useful to reveal if it is a valid return address.

0:000> kc 2
Call Site
ntdll!NtWaitForSingleObject
ntdll!RtlReportExceptionEx
0:000> dqs @rsp L3
00000000`0012d7b8  00000000`77983072 ntdll!RtlReportExceptionEx+0x1d2
00000000`0012d7c0  00000000`00000000
00000000`0012d7c8  00000000`004ba81a TB5OTx64+0xca81a
0:000> ub 00`77983072
ntdll!RtlReportExceptionEx+0x1bc:
00000000`7798305c f8              clc
00000000`7798305d 0000            add     byte ptr [rax],al
00000000`7798305f 00483b          add     byte ptr [rax+3Bh],cl
00000000`77983062 df74394d        fbstp   tbyte ptr [rcx+rdi+4Dh]
00000000`77983066 8bc6            mov     eax,esi
00000000`77983068 b201            mov     dl,1
00000000`7798306a 488bcb          mov     rcx,rbx
00000000`7798306d e87ee2f8ff      call    ntdll!NtWaitForSingleObject     (00000000`779112f0)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM