背景

昨天，一位朋友找到我尋求幫助。他的項目需要調(diào)用一個第三方項目的webAPI。這個webAPI本身可從header, query string中取相關信息，但同事發(fā)現(xiàn)他在調(diào)用時，無法按期望的那樣從query string中傳參數(shù)給到第三方webAPI (webAPI仿佛忽略了從query string過來的信息)，朋友不知道是這個webAPI的問題，還是自己調(diào)用代碼的問題了。。

由于這個webAPI service是他們公司內(nèi)部的某team的項目，所以朋友雖然可以看到源碼，但他并不能快速確定原因, 維護項目的人又不好找。通過webAPI service代碼他自己找到了可疑的原因是webAPI中的這個方法有可能阻擋了他期望的webAPI行為:?Instance.EnableFallback()?(公司隱私，改了名), 但他無法確定這個方法在實際運行的時候的具體返回值。

聽了朋友介紹，我能想到的一個方法是看一下他們公司的這個第三方的service進程的內(nèi)部情況?

（非生產(chǎn)環(huán)境，權限是允許的）

分析

通過kubectl exec -it [namespace:pod] /bin/bash，我們成功進入了service的pod里。雖然是非生產(chǎn)環(huán)境，我們也盡量別打擾人家干活

? 那么…就選擇dump一下運行的dotnet進程嘍

由于這次的任務是觀察托管環(huán)境的某個內(nèi)存位置的值，我選擇了用dotnet-dump

?

然后dotnet-dump analyze core_123?開始分析。

我們想要的是?Instance.EnableFallback?的返回值，而我的朋友已經(jīng)知道這個Instance的type，所以用dumpheap -type找一下這個instance在哪里：

?然后用!do一下instance具體內(nèi)容：

1?>?do?796f3840d0802?Name: ? ? ? ?XXX.Common.XXX.XXXInstance3?MethodTable: 00007970d459d3a84?EEClass: ? ? 00007970d45a4fc05?Size: ? ? ? ?80(0x50) bytes6?File: ? ? ? ?/app/XXX.dll7?Fields:8?? ? ? ? ? ? ?MT ? ?Field ? Offset ? ? ? ? ? ? ? ? Type VT ? ? Attr ? ? ? ? ? ?Value Name9?00007970d459d9e8 ?4000016?? ? ??10?...XXX]] ?0?instance 0000796f3840d130 _evs

根據(jù)簡化和隱藏敏感信息后的代碼:

?

?知道了需要繼續(xù)用!do?看這個0000796f3840d130:

1?>?do?0000796f3840d130?2?Name: ? ? ? ?System.Collections.Generic.Dictionary`2[[System.String, System.Private.CoreLib],[XXX.Common.XXX.XXXEnv, XXX]]?3?MethodTable: 00007970d459d718?4?EEClass: ? ? 00007970ce610c00?5?Size: ? ? ? ?72(0x48) bytes?6?File: ? ? ? ?/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.32/System.Private.CoreLib.dll?7?Fields:?8?? ? ? ? ? ? ?MT ? ?Field ? Offset ? ? ? ? ? ? ? ? Type VT ? ? Attr ? ? ? ? ? ?Value Name?9?00007970ce636448 ?4001aec ? ? ? ?8?? ? ? System.Int32[] ?0?instance 0000796f384143a8 _buckets10?00007970ce636250 ?4001aed ? ? ??10?...ivate.CoreLib]][] ?0?instance 0000796f384143d0 _entries11?00007970ce5fa0e8 ?4001aee ? ? ??30?? ? ? ? System.Int32 ?1?instance ? ? ? ? ? ? ? ?1?_count

大家如果了解.net Dictionary類型的實現(xiàn)，就知道目前這個dictionary是1size且具體的item值可以直接用!dp看：

?

?Dictionary里的_entries是個數(shù)組，item類型是value type，所以是inlined memory,?所以直接看0000796f38412948, 因為他是數(shù)組中第0個元素里的key-value pair里的value(XXXEnv instance的地址）。

1?>?do?0000796f384129482?Name: ? ? ? ?XXX.Common.XXXEnv3?MethodTable: 00007970d459e7004?EEClass: ? ? 00007970d45a58885?Size: ? ? ? ?56(0x38) bytes6?File: ? ? ? ?/app/XXX.dll7?Fields:8?? ? ? ? ? ? ?MT ? ?Field ? Offset ? ? ? ? ? ? ? ? Type VT ? ? Attr ? ? ? ? ? ?Value Name9?00007970d340a988 ?400000a ? ? ? ?8?....Config.XXXConfig ?0?instance 0000796f382898f0 _toggleConfig

最后看那個_toggleConfig，Instance.EnableFallback()里面一通調(diào)用最終會讀它的內(nèi)容，簡化代碼如下：

?

?所以繼續(xù)!do看一下這個_toggleConfig:

?

?至此原因確定，懷疑的這個方法在當前這個webAPI service下會返回false.

后記

也許有朋友會問，直接dump type是XXXConfig的instance不就行了。是的，不過在這個dump文件中，我發(fā)現(xiàn)了不止一個active的XXXConfig instance, 也就是說不止一處會用到這個不唯一的XXXConfig, 而我需要明確Instance.EnableFallback最終的返回，所以需要耐心探索哈?

總結

我的朋友知道了他想確定的Instance.EnableFallback在第三方service運行的時候的真實值之后，也明確了他那邊的應對這個webAPI的調(diào)用方式了。

這次診斷的問題雖不是cpu過高、內(nèi)存泄漏這類資源問題，但還是用上了與排查資源泄漏相同的底層調(diào)試診斷技術來解決。最后我的朋友很高興，吃了個定心丸