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

如何确定对象被固定的原因

发布于 2024-08-07 20:41:38 字数 6030 浏览 4 评论 0原文

我试图找出为什么我的应用程序中的某些对象被固定。到目前为止我查看的对象是对象数组！gcroot 显示该数组被固定，但我不知道如何找出它被固定的原因。

输出：

0:000> !dumpobj 0239cea0
Name: System.Object[]
MethodTable: 793041d0
EEClass: 790eda54
Size: 528(0x210) bytes
Array: Rank 1, Number of elements 128, Type CLASS
Element Type: System.Object
Fields:
None

0:000> !gcroot 0239cea0
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread f3c
Scan Thread 2 OSTHread e54
Scan Thread 4 OSTHread 748
Scan Thread 5 OSTHread fe0
Scan Thread 7 OSTHread 7a0
Scan Thread 9 OSTHread cf4
Scan Thread 10 OSTHread a6c
Scan Thread 11 OSTHread bc4
Scan Thread 12 OSTHread 598
Scan Thread 13 OSTHread a8
Scan Thread 14 OSTHread 50c
Scan Thread 15 OSTHread ba4
Scan Thread 16 OSTHread b40
Scan Thread 17 OSTHread 534
Scan Thread 18 OSTHread 5fc
Scan Thread 19 OSTHread dfc
Scan Thread 20 OSTHread cc4
Scan Thread 21 OSTHread f84
Scan Thread 22 OSTHread 9f4
Scan Thread 23 OSTHread ff0
Scan Thread 24 OSTHread fb0
Scan Thread 25 OSTHread c14
Scan Thread 29 OSTHread 5c4
DOMAIN(0015EB90):HANDLE(Pinned):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])

编辑：添加了 !eeheap -gc 输出

!eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x49a6f940
generation 1 starts at 0x49a0c8a8
generation 2 starts at 0x01301000
ephemeral segment allocation context: none
 segment    begin allocated     size
01300000 01301000  022f05a0 0x00fef5a0(16709024)
0d0d0000 0d0d1000  0e0bb0cc 0x00fea0cc(16687308)
0e9e0000 0e9e1000  0f9de3e8 0x00ffd3e8(16765928)
11020000 11021000  12014808 0x00ff3808(16726024)
15020000 15021000  15ff3958 0x00fd2958(16591192)
139f0000 139f1000  1499f584 0x00fae584(16442756)
16020000 16021000  16fd7c30 0x00fb6c30(16477232)
19020000 19021000  1a013df4 0x00ff2df4(16723444)
17020000 17021000  17fcfe8c 0x00faee8c(16445068)
18020000 18021000  18fedb84 0x00fccb84(16567172)
1a020000 1a021000  1afc8814 0x00fa7814(16414740)
26010000 26011000  26f97d2c 0x00f86d2c(16280876)
2d010000 2d011000  2df97210 0x00f86210(16278032)
20010000 20011000  210028e0 0x00ff18e0(16718048)
21010000 21011000  220085d8 0x00ff75d8(16741848)
23810000 23811000  247acf60 0x00f9bf60(16367456)
28010000 28011000  28f84f80 0x00f73f80(16203648)
1c010000 1c011000  1cfba544 0x00fa9544(16422212)
1d010000 1d011000  1dfdcf64 0x00fcbf64(16564068)
32010000 32011000  32f9189c 0x00f8089c(16255132)
1e010000 1e011000  1eff9824 0x00fe8824(16680996)
2c010000 2c011000  2cfd4904 0x00fc3904(16529668)
300a0000 300a1000  3104a488 0x00fa9488(16422024)
24810000 24811000  2571bd20 0x00f0ad20(15772960)
36d10000 36d11000  37c982d4 0x00f872d4(16282324)
29010000 29011000  29fc96a0 0x00fb86a0(16484000)
27010000 27011000  27ee38bc 0x00ed28bc(15542460)
2a010000 2a011000  2afab094 0x00f9a094(16359572)
441c0000 441c1000  45149df0 0x00f88df0(16289264)
38d10000 38d11000  39ce4254 0x00fd3254(16593492)
3bd10000 3bd11000  3cc7a750 0x00f69750(16160592)
3ad10000 3ad11000  3bc8b878 0x00f7a878(16230520)
411c0000 411c1000  421655a0 0x00fa45a0(16401824)
2b010000 2b011000  2bfafae4 0x00f9eae4(16378596)
461c0000 461c1000  471a1bb0 0x00fe0bb0(16649136)
3e1c0000 3e1c1000  3f11151c 0x00f5051c(16057628)
34010000 34011000  35003ae4 0x00ff2ae4(16722660)
451c0000 451c1000  4609e680 0x00edd680(15586944)
4c1c0000 4c1c1000  4d105324 0x00f44324(16007972)
2f0a0000 2f0a1000  3007989c 0x00fd889c(16615580)
50e10000 50e11000  51cf17d8 0x00ee07d8(15599576)
33010000 33011000  34005d88 0x00ff4d88(16731528)
37d10000 37d11000  38cc6d7c 0x00fb5d7c(16473468)
481c0000 481c1000  4898a468 0x007c9468(8164456)
39d10000 39d11000  3acbe2d8 0x00fad2d8(16437976)
3f1c0000 3f1c1000  3fd1f378 0x00b5e378(11920248)
51e10000 51e11000  52e01018 0x00ff0018(16711704)
431c0000 431c1000  441805d8 0x00fbf5d8(16512472)
401c0000 401c1000  4116b2b0 0x00faa2b0(16425648)
421c0000 421c1000  430da254 0x00f19254(15831636)
491c0000 491c1000  49b98e0c 0x009d7e0c(10321420)
Large object heap starts at 0x02301000
 segment    begin allocated     size
02300000 02301000  02f1bf20 0x00c1af20(12693280)
Total Size  0x31786160(829972832)
------------------------------
GC Heap Size  0x31786160(829972832)
原文

I am trying to track down why some objects in my application are pinned. The objects I have looked at so far are object arrays !gcroot is showing the array as being pinned but I do not know how to figure out why it is pinned.

Output:

0:000> !dumpobj 0239cea0
Name: System.Object[]
MethodTable: 793041d0
EEClass: 790eda54
Size: 528(0x210) bytes
Array: Rank 1, Number of elements 128, Type CLASS
Element Type: System.Object
Fields:
None

0:000> !gcroot 0239cea0
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread f3c
Scan Thread 2 OSTHread e54
Scan Thread 4 OSTHread 748
Scan Thread 5 OSTHread fe0
Scan Thread 7 OSTHread 7a0
Scan Thread 9 OSTHread cf4
Scan Thread 10 OSTHread a6c
Scan Thread 11 OSTHread bc4
Scan Thread 12 OSTHread 598
Scan Thread 13 OSTHread a8
Scan Thread 14 OSTHread 50c
Scan Thread 15 OSTHread ba4
Scan Thread 16 OSTHread b40
Scan Thread 17 OSTHread 534
Scan Thread 18 OSTHread 5fc
Scan Thread 19 OSTHread dfc
Scan Thread 20 OSTHread cc4
Scan Thread 21 OSTHread f84
Scan Thread 22 OSTHread 9f4
Scan Thread 23 OSTHread ff0
Scan Thread 24 OSTHread fb0
Scan Thread 25 OSTHread c14
Scan Thread 29 OSTHread 5c4
DOMAIN(0015EB90):HANDLE(Pinned):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[])

Edit: Added !eeheap -gc output

!eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x49a6f940
generation 1 starts at 0x49a0c8a8
generation 2 starts at 0x01301000
ephemeral segment allocation context: none
 segment    begin allocated     size
01300000 01301000  022f05a0 0x00fef5a0(16709024)
0d0d0000 0d0d1000  0e0bb0cc 0x00fea0cc(16687308)
0e9e0000 0e9e1000  0f9de3e8 0x00ffd3e8(16765928)
11020000 11021000  12014808 0x00ff3808(16726024)
15020000 15021000  15ff3958 0x00fd2958(16591192)
139f0000 139f1000  1499f584 0x00fae584(16442756)
16020000 16021000  16fd7c30 0x00fb6c30(16477232)
19020000 19021000  1a013df4 0x00ff2df4(16723444)
17020000 17021000  17fcfe8c 0x00faee8c(16445068)
18020000 18021000  18fedb84 0x00fccb84(16567172)
1a020000 1a021000  1afc8814 0x00fa7814(16414740)
26010000 26011000  26f97d2c 0x00f86d2c(16280876)
2d010000 2d011000  2df97210 0x00f86210(16278032)
20010000 20011000  210028e0 0x00ff18e0(16718048)
21010000 21011000  220085d8 0x00ff75d8(16741848)
23810000 23811000  247acf60 0x00f9bf60(16367456)
28010000 28011000  28f84f80 0x00f73f80(16203648)
1c010000 1c011000  1cfba544 0x00fa9544(16422212)
1d010000 1d011000  1dfdcf64 0x00fcbf64(16564068)
32010000 32011000  32f9189c 0x00f8089c(16255132)
1e010000 1e011000  1eff9824 0x00fe8824(16680996)
2c010000 2c011000  2cfd4904 0x00fc3904(16529668)
300a0000 300a1000  3104a488 0x00fa9488(16422024)
24810000 24811000  2571bd20 0x00f0ad20(15772960)
36d10000 36d11000  37c982d4 0x00f872d4(16282324)
29010000 29011000  29fc96a0 0x00fb86a0(16484000)
27010000 27011000  27ee38bc 0x00ed28bc(15542460)
2a010000 2a011000  2afab094 0x00f9a094(16359572)
441c0000 441c1000  45149df0 0x00f88df0(16289264)
38d10000 38d11000  39ce4254 0x00fd3254(16593492)
3bd10000 3bd11000  3cc7a750 0x00f69750(16160592)
3ad10000 3ad11000  3bc8b878 0x00f7a878(16230520)
411c0000 411c1000  421655a0 0x00fa45a0(16401824)
2b010000 2b011000  2bfafae4 0x00f9eae4(16378596)
461c0000 461c1000  471a1bb0 0x00fe0bb0(16649136)
3e1c0000 3e1c1000  3f11151c 0x00f5051c(16057628)
34010000 34011000  35003ae4 0x00ff2ae4(16722660)
451c0000 451c1000  4609e680 0x00edd680(15586944)
4c1c0000 4c1c1000  4d105324 0x00f44324(16007972)
2f0a0000 2f0a1000  3007989c 0x00fd889c(16615580)
50e10000 50e11000  51cf17d8 0x00ee07d8(15599576)
33010000 33011000  34005d88 0x00ff4d88(16731528)
37d10000 37d11000  38cc6d7c 0x00fb5d7c(16473468)
481c0000 481c1000  4898a468 0x007c9468(8164456)
39d10000 39d11000  3acbe2d8 0x00fad2d8(16437976)
3f1c0000 3f1c1000  3fd1f378 0x00b5e378(11920248)
51e10000 51e11000  52e01018 0x00ff0018(16711704)
431c0000 431c1000  441805d8 0x00fbf5d8(16512472)
401c0000 401c1000  4116b2b0 0x00faa2b0(16425648)
421c0000 421c1000  430da254 0x00f19254(15831636)
491c0000 491c1000  49b98e0c 0x009d7e0c(10321420)
Large object heap starts at 0x02301000
 segment    begin allocated     size
02300000 02301000  02f1bf20 0x00c1af20(12693280)
Total Size  0x31786160(829972832)
------------------------------
GC Heap Size  0x31786160(829972832)

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

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

发布评论

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

评论（3）

双手揣兜 2024-08-14 20:41:38

GCRoot 通常不会告诉您为什么某些内容被固定。 CLR 中的许多对象数组都用于内部事物。相反，阅读您对其他答案的评论，我是否可以建议您首先从不同的东西开始来追踪内存泄漏？

从“!dumpheap -stat”开始，查看那里最大的内存用户。但是，请忽略基本的 CLR 类型，例如 object[]、string 等。查找其中存在哪些您的对象（定义为“不是 mscorlib 或 system.dll 中的某些内容）”，并找出其中的内容从该方向追踪泄漏通常更容易，即使事实证明您正在泄漏应用程序中的原始类型，

这通常是我在 CLR 中追踪托管泄漏的方式。它对于大多数泄漏都相当有效。

GCRoot will not generally tell you why something is pinned. A lot of the object arrays that you find in CLR are used for internal things. Instead, reading your comment on the other answer, could I suggest that you first start with something different to track down your memory leak?

Start with "!dumpheap -stat" and look at the biggest memory users there. However, ignore the basic CLR types such as object[], string, etc. Find which of your objects (defined as "not something in mscorlib or system.dll) that are there, and find out what roots those. It's usually easier to track down a leak from that direction, even if it turns out that you are leaking a primitive types in your application.

This is usually how I track down managed leaks in CLR, and it works fairly well for most leaks.

回复 原文
┈┾☆殇 2024-08-14 20:41:38

中的 !findroots 命令。 NET 4 的 SOS（或 SOSEX 中的 !refs）等待，直到下一次GC（您可以指定哪一代）然后会告诉您该对象有哪些根。

The !findroots command in .NET 4's SOS (or !refs in SOSEX) waits until the next GC (you can specify which generation) and will then tell you what roots the object has.

回复 原文
￡噩梦荏苒 2024-08-14 20:41:38

根据我的经验，查看 Object[] 几乎没有什么用处，因为它是许多类型的基础类型，这意味着您最终会在堆上得到很多这样的类型，这使得它变得更加困难以确定正确的一个。此外还有内部结构，例如驻留字符串表 也存储为 Object[]。

如果您试图找出应用程序使用大量内存的原因，请尝试识别可能或可能不封装 Object[] 的其他类型，并找出这些类型的根源。

如果您提供有关您想要完成的任务的更多信息，我也许能够提供更具体的建议。

编辑：碎片并不一定像听起来那么糟糕，而且 100 MB 的可用空间并没有让我觉得是一个惊人的高数字。您是否已确定空闲块是否位于大对象堆上的分代堆中？

!eeheap -gc 的输出是什么？

In my experience it is rarely useful to look at Object[] as it is the underlying type of a lot of types, which means that you'll end up with lots of these on the heap making it harder to identify the correct one. Additionally internal structures such as the interned string table is also stored as an Object[].

If you are trying to figure out why the application uses a lot of memory, try to identify other types that may or may not encapsulate Object[] and find out what roots these.

If you provide more information on what you're trying to accomplish I may be able to provide more specific advice.

EDIT: Fragmentation isn't necessarily as bad as it may sound and 100 MB free doesn't strike me as an alarming high number. Have you identified if the free blocks are in the generational heap on on the large object heap?

What is the output of !eeheap -gc?

回复 原文
~没有更多了~

关于作者

心凉怎暖

暂无简介

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

相关话题

更多

热门标签

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

推荐作者

娇女薄笑

文章 0 评论 0

biaggi

文章 0 评论 0

xiaolangfanhua

文章 0 评论 0

rivulet

文章 0 评论 0

我三岁

文章 0 评论 0

薆情海

文章 0 评论 0

更多

友情链接

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