Причины сбоев при сборе мусора
Я в течение некоторого времени боролся с сбоем в приложении C #, которое также использует значительную долю модулей C + +/CLI, которые в основном являются оболочками вокруг собственных библиотек для доступа к драйверам устройств. Авария не всегда легко воспроизводима, но я смог собрать полдюжины дампов, которые показывают, что программа всегда терпит крах с нарушением доступа во время сбора мусора. Это собственный стек вызовов и последний журнал событий:
0:000> k
ChildEBP RetAddr
0012d754 79f95a8f mscorwks!WKS::gc_heap::find_first_object+0x62
0012d7dc 79f933bb mscorwks!WKS::gc_heap::mark_through_cards_for_segments+0x493
0012d814 79f92cbf mscorwks!WKS::gc_heap::mark_phase+0xc3
0012d838 79f93245 mscorwks!WKS::gc_heap::gc1+0x62
0012d84c 79f92f5a mscorwks!WKS::gc_heap::garbage_collect+0x253
0012d878 79f94e26 mscorwks!WKS::GCHeap::GarbageCollectGeneration+0x1a9
0012d904 79f926ce mscorwks!WKS::gc_heap::try_allocate_more_space+0x15b
0012d918 79f92769 mscorwks!WKS::gc_heap::allocate_more_space+0x11
0012d938 79e73291 mscorwks!WKS::GCHeap::Alloc+0x3b
0:000> .lastevent
Last event: 7e8.88: Access violation - code c0000005 (first/second chance not available)
debugger time: Mon Sep 26 11:34:53.646 2011 (UTC + 2:00)
Поэтому позвольте мне сначала задать свой вопрос и дать более подробную информацию ниже. Мой вопрос: кроме управляемой порчи кучи, есть ли еще какая-то причина для крушения во время сбора мусора ?
Теперь, разрабатывая немного, причина, по которой я спрашиваю это, заключается в том, что мне очень трудно пытаться идентифицировать код, который повреждает управляемую кучу и не может найти образец для памяти, которая (предположительно) перезаписана.
Я уже пытался прокомментировать весь «опасный» код C + +/CLI (особенно части, которые используют прикрепленные ручки), но это не помогло. Пытаясь найти образец в памяти, который был перезаписан, я посмотрел на разобранный код в точке сбоя:
0:000> u .-a .+a
mscorwks!WKS::gc_heap::find_first_object+0x54:
79f935b9 89450c mov dword ptr [ebp+0Ch],eax
79f935bc 8bd0 mov edx,eax
79f935be 8b02 mov eax,dword ptr [edx]
79f935c0 83e0fe and eax,0FFFFFFFEh
79f935c3 f70000000080 test dword ptr [eax],80000000h <<<<CRASH
79f935c9 0f84b1000000 je mscorwks!WKS::gc_heap::find_first_object+0x73
0:000> r
eax=00000000 ebx=01c81000 ecx=01c80454 edx=01c82fe0 esi=012f0000 edi=000027e1
eip=79f935c3 esp=0012d738 ebp=0012d754 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
mscorwks!WKS::gc_heap::find_first_object+0x62:
79f935c3 f70000000080 test dword ptr [eax],80000000h ds:0023:00000000=????????
Сбой происходит при попытке отменить привязку регистра EAX, который является нулевым. Теперь из того, что я вижу, EAX был загружен из содержимого, указанного регистром EDX, поэтому я посмотрел на адрес, хранящийся там:
0:000> dd @edx-10
01c82fd0 06542778 00000000 00000000 01c82494
01c82fe0 00000000 00000000 00000000 00000000
01c82ff0 01b641d0 00000000 00000000 01c82380
EDIT: Теперь я вижу, что мой анализ был неправильным, отсутствовал понимание режимов адресации x86.
Таким образом, я могу видеть, что начиная с адреса 01c82fed (значение, сохраненное в EDX) следующие 16 байт равны null. Но, глядя на другой похожий аварийный дамп, я вижу следующее:
0:000> dd @edx-10
018defd4 00000000 00000000 00000000 00000000
018defe4 00000000 00000000 018b468c 01742354
018deff4 00e0907f 00000000 00000000 00000000
Итак, здесь 16 байт перед адресом, указанным EDX, и следующие 8 из них являются нулевыми. И то же самое происходит в других краш-дампах, которые у меня есть, я не вижу здесь шаблона, то есть не кажется, что какая-то часть кода просто перезаписывает эту область памяти.
Возвращаясь к вопросу, что я хотел бы знать, есть ли какое-то другое объяснение краха, помимо одной части кода, перезаписывающей память, которую он не должен. Или любой совет вообще в том, как действовать, я действительно потерялся в этом здесь..
(могут ли прикрепленные ручки вызвать проблему? У нас их довольно много и то, что я думаю, что это забавно, это то, что я всегда вижу 137 - не больше и не меньше - прикрепленные ручки с! gchandles в момент крушения, это странное совпадение для меня..).
ИЗМЕНИТЬ : забыли упомянуть, что мы используем версию 3,5 рамки .Net. Я вижу сообщения о подобных сбоях в .Net 4, когда фоновый GC активен (где-то есть упоминание, что это ошибка в .Net), но я не думаю, что это актуально здесь, так как AFAIK нет фонового GC в .Net 3.5.