Ситуация отладки нехватки памяти, когда дамп памяти показывает очень мало используемой памяти - PullRequest
Новая
       36

Ситуация отладки нехватки памяти, когда дамп памяти показывает очень мало используемой памяти

0 голосов
/ 11 июня 2018

У меня есть процесс C # / Managed, который завершился неудачей с исключением из-за недостатка памяти, но проверка дампа показывает, что фактически используется очень мало памяти.Я надеюсь на некоторую помощь в выяснении следующих шагов для расследования.

У меня есть полный дамп памяти нарушающего процесса, и я использую WinDBG с SOS, чтобы попытаться выяснить, что происходит.

  1. Размер дампа памяти равен 1,949,280,487 bytes
  2. !EEHeap -gc дает GC Heap Size: Size: 0xd8dcd0 (14,212,304) bytes. !VerifyHeap и !DumpHeap -stat показывать согласованные числа, поэтому я думаю, что я должен смотреть на собственную память, а не на управляемую память
  3. !heap -s показывает одну кучу с 1,409,884 k Commit, которая выглядит многообещающе (подробности ниже)
  4. !heap -stat -h 01740000 (для кучи 1,4 ГБ) указывает на минимальный объем используемой памяти (подробности ниже).Первая запись имеет общий размер 0x25fec=155,628 bytes и вызывает 2,98% от «общего количества занятых байтов». Это может указывать на 5,222,416 общее количество занятых байтов, которое даже не сопоставимо с размером фиксации кучи.

На этом этапе я заканчиваю то, что считаю компетентным расследовать, и перехожу в область диких спекуляций.

  • Может быть, это просто фрагментация памяти?Кажется, что ~ 1,4 ГБ коммитов по сравнению с ~ 5 МБ в использовании - это большой путь, который можно объяснить фрагментацией.
  • !address показывает огромные полосы чередования между 0x41000 PAGE_READWRITE и 0x1000 PAGE_NOACCESS.Что может объяснить все это?
  • Внутри блоков PAGE_READWRITE содержимое в основном равно нулю, а
    • db 7fdd8000 L41000 показывает в основном нулевые байты с повторениями одной и той же строки с вкраплениями
    • например, dU 7fdd804C дает 0=goog_update_data.3=adk%3D1111111111%26tt%3D1111111%26bs%3D1111%2C111%26mtos%3D0%2C1111111%2C1111111%2C1111111%2C1111111%26tos%3D0%2C1111111%2C0%2C0%2C0%26p%3D111%2C111%2C111%2C1111%26iehp%3D1%26mcvt%3D1111111%26rs%3D3%26ht%3D0%26tfs%3D1111%26tls%3D1111111%26mc%3D0.11%26lte%3D-1%26bas%3D0%26bac%3D0%26avms%3Dgeo%26bos%3D1111%2C1111%26ps%3D1111%2C1111%26ss%3D1920%2C1080%26pt%3D0%26d (потенциально чувствительные числа заменены на 1, который HTML декодирует до 0=goog_update_data.3=adk=1111111111&tt=1111111&bs=1111,111&mtos=0,1111111,1111111,1111111,1111111&tos=0,1111111,0,0,0&p=111,111,111,1111&iehp=1&mcvt=1111111&rs=3&ht=0&tfs=1111&tls=1111111&mc=0.11<e=-1&bas=0&bac=0&avms=geo&bos=1111,1111&ps=1111,1111&ss=1920,1080&pt=0&d
    • Одна и та же строка повторяется несколько раз в пределах блока
    • рассматриваемое приложениесодержит управляемый элемент управления WebBrowser. Возможно ли, что это утечка JavaScript на размещенной веб-странице, а не утечка самого моего приложения?
    • Являются ли эти PAGE_NOACCESS некоторой формой защиты от переполнения буфера? Эта куча выполняет какую-то странную отладкуGФлаги, о которых я не знаю?

!heap -s

LFH Key                   : 0xd4a58b52
Termination on corruption : DISABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
01740000 00000002 1409924 1409884 1409868    416   320   293    2      0   LFH
014e0000 00001002     116     64     60     10     7     1    0      0   LFH
01c20000 00001002   53284  52388  53228    491   116    14    0      0   LFH
03590000 00001002      60      4     60      0     1     1    0      0      
01b80000 00041002      60      4     60      2     1     1    0      0      
05a50000 00001002    1136    124   1080     24    10     2    0      0   LFH
05b40000 00001002      60     12     60      4     2     1    0      0      
061f0000 00041002     116     64     60     16     4     1    0      0   LFH
07410000 00001002      60     12     60      4     2     1    0      0      
073f0000 00001002    3180   1156   3124     51    37     3    0      0   LFH
09b60000 00001002    3180   1716   3124     17     7     3    0      0   LFH
09af0000 00001002      60      4     60      2     1     1    0      0      
0ece0000 00001002      60      8     60      6     1     1    0      0      
13140000 00001002    1136    336   1080    301    10     2    0      0   LFH
13130000 00001002    1136    116   1080     42    13     2    0      0   LFH
133a0000 00001002     180     68    124     42     6     1    0      0   LFH
-----------------------------------------------------------------------------

!heap -stat -h 01740000

 heap @ 01740000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    25fec 1 - 25fec  (2.98)
    23d0c 1 - 23d0c  (2.81)
    2000 f - 1e000  (2.36)
    1c843 1 - 1c843  (2.24)
    10 1896 - 18960  (1.93)
    17b8c 1 - 17b8c  (1.86)
    50 434 - 15040  (1.65)
    a36c 2 - 146d8  (1.60)
    114 10a - 11ec8  (1.41)
    c 17a7 - 11bd4  (1.39)
    84 215 - 112d4  (1.35)
    4000 4 - 10000  (1.26)
    fc24 1 - fc24  (1.24)
    10c9 f - fbc7  (1.24)
    3bc 43 - fa34  (1.23)
    80 1e2 - f100  (1.18)
    800 1e - f000  (1.18)
    4fe8 3 - efb8  (1.18)
    12c9 c - e16c  (1.11)
    d0 10b - d8f0  (1.06)

!address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Heap                                  11774          5a0b8000 (   1.407 GB)  70.78%   70.35%
<unknown>                              1652          131f3000 ( 305.949 MB)  15.03%   14.94%
Image                                  1090          10649000 ( 262.285 MB)  12.88%   12.81%
Stack                                    93           1a10000 (  26.063 MB)   1.28%    1.27%
Free                                    399            c4f000 (  12.309 MB)            0.60%
Other                                    14             53000 ( 332.000 kB)   0.02%    0.02%
TEB                                      31             47000 ( 284.000 kB)   0.01%    0.01%
PEB                                       1              3000 (  12.000 kB)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE                           13378          67145000 (   1.611 GB)  81.02%   80.53%
MEM_IMAGE                              1199          12bf5000 ( 299.957 MB)  14.74%   14.65%
MEM_MAPPED                               78           5667000 (  86.402 MB)   4.24%    4.22%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT                            13802          758dc000 (   1.837 GB)  92.40%   91.84%
MEM_RESERVE                             853           9ac5000 ( 154.770 MB)   7.60%    7.56%
MEM_FREE                                399            c4f000 (  12.309 MB)            0.60%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE                         7089          5dd90000 (   1.466 GB)  73.76%   73.32%
PAGE_EXECUTE_READ                       164           c603000 ( 198.012 MB)   9.73%    9.67%
PAGE_READONLY                           431           8d13000 ( 141.074 MB)   6.93%    6.89%
PAGE_NOACCESS                          5698           1642000 (  22.258 MB)   1.09%    1.09%
PAGE_WRITECOPY                          211            cee000 (  12.930 MB)   0.64%    0.63%
PAGE_EXECUTE_READWRITE                   87            291000 (   2.566 MB)   0.13%    0.13%
PAGE_EXECUTE_WRITECOPY                   38            12f000 (   1.184 MB)   0.06%    0.06%
PAGE_EXECUTE                             20             a7000 ( 668.000 kB)   0.03%    0.03%
PAGE_READWRITE|PAGE_GUARD                64             9f000 ( 636.000 kB)   0.03%    0.03%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Heap                                        178af000            346000 (   3.273 MB)
<unknown>                                    f613000           1ead000 (  30.676 MB)
Image                                       63341000           10ae000 (  16.680 MB)
Stack                                        de80000             fd000 (1012.000 kB)
Free                                               0             10000 (  64.000 kB)
Other                                       7f2a0000             23000 ( 140.000 kB)
TEB                                          10cc000              3000 (  12.000 kB)
PEB                                          10ba000              3000 (  12.000 kB)

!address (подмножество результатов 

7f3d8000 7f419000    41000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f419000 7f41a000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_NOACCESS                      Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f41a000 7f45b000    41000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f45b000 7f45c000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_NOACCESS                      Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f45c000 7f49d000    41000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f49d000 7f49e000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_NOACCESS                      Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f49e000 7f4df000    41000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f4df000 7f4e0000     1000 MEM_PRIVATE MEM_COMMIT  PAGE_NOACCESS                      Heap       [ID: 0; Handle: 01740000; Type: Segment]
7f4e0000 7f521000    41000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Heap       [ID: 0; Handle: 01740000; Type: Segment]

1 Ответ

0 голосов
/ 30 июня 2018

Спасибо всем за помощь и советы по этому вопросу.В конечном итоге мы смогли изолировать нарушающий компонент от размещенного WinForms WebBrowserControl, который загружал внешнюю страницу, которая сама по себе просачивалась в браузере.Мы смогли смягчить проблему, просто изменив конфигурацию, чтобы больше не загружать эту устаревшую и ошибочную страницу в нашу панель инструментов (нам повезло, что она больше не была полезна).

В ретроспективе все признаки были в наличиичто утечка не была ни управляемой (.NET), ни чисто нативной, поскольку ни один из опробованных нами инструментов не сузил ее.

...