Странная, зависящая от версии .NET Framework, проблема со сборкой мусора?

Question

[Александр Вишняков]

В моём проекте есть интересный баг с юнит-тестами, который проявляется только в .NET 4.5, но не в .NET 4.0. Здесь находится исходный код, а здесь — архив с бинарниками.

Шаги, чтобы воспроизвести проблему:
1. Скачайте исходный код и бинарники
2. Скопируйте папку Binary в папку Interop\Main\
3. Запустите unit тесты из сборки Interop.Core.Tests.NETFX45

Тест IsAliveAfterCollectionWork должен упасть. Если вы попробуете посмотреть память с помощью профайлера (я использую бесплатный dotMemory 4.0 EAP с настройками Profile .NET process -> Collection every N-th object: 1, Memory traffic: Collect и Use profiler API), то вы увидете, что массив MarkedObject[] не собирается сборщиком мусора, хотя на него нет никаких ссылок.

Моя конфигурация:
- Windows 8.1
- .NET Framework 4.5.1
- Я использую Visual Studio 2012, но 2010 и 2013 тоже установлены

Answer 1

[mayorovp]

А что тут странного? GC вам ничем не обязан, если объект перешел в следующее поколение - Collect его может проигнорировать.

Попробуйте GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true);

Comments

[Александр Вишняков]

Как так не обязан?! Если вы смотрели исходный код, то там вызывается цепочка Gollect -> WaitForPendingFinalizers -> Collect, т.е. должна выполняться полная сборка мусора. Впрочем, замена Collect() на предложенную перегрузку не помогла. И не могла помочь, ибо внутри себя Collect вызывает внутренний метод с параметрами, эквивалентными тем, что задаёт предложенная вами перегрузка. Массив находится во втором поколении и при любом количестве повторов вызова приведённой мной конструкции всё равно не удаляется из памяти, хотя второе поколение - последние и, следовательно, перейти "в следующее поколение" он уже не может (поскольку такого просто нет).

Answer 2

[andreycha]

В дебаг-режиме локальные переменные оставляются в живых до конца текущего скоупа. Это сделано для того, чтобы работали функции Locals, Auto, т.е. чтобы вы в любой момент при отладке могли посмотреть состояния локальных переменных. У меня скорее вопрос почему тест у вас не падает в 4.0.

Comments

[Александр Вишняков]

Да, я рассматривал такое предположение. Но в данном случае ведь, вроде бы, scope — это тело текущего метода/теста (IsAliveAfterCollectionWork), а объекты, которые не собираются, создаются гораздо выше по цепочке вызовов и в самом методе никак не используются... Точнее, там используется только один объект, который и должен оставаться в живых, а на остальных есть только слабые ссылки. К тому же, при замене массива на IEnumerable вместо четырёх объектов (массив+тестируемый) остаются два (один объект из IEnumerable + тестируемый).

Answer 3

[Илья Глебов]

Собрал VS 13 из исходников.

Если запускать Resharper'овским test runner'ом - тест проходит
Если запускать Resharper'овским test runner'ом в debug - тест падает
Если запускать VS test runner'ом - тест падает

Если сделать консольное приложение - то остается 1 объект в WeakReferencesStorage

Возможно стоить копать в сторону работы GC в debug окружении

Comments

[Александр Вишняков]

Хм. Странно. У меня в ReSharper'овском test runnner'е падает даже без дебага. Или он по-умолчнию использует debug и вы вырезали debug-версию, оставляя только release и затем запускали? Хотя в любом случае спасибо. Есть идея что это происходит из-за того, что в debug'е GC =вроде бы= оставляет переменные в живых до конца выполнения метода. Хотя когда я пробовал сделать всё через статические поля, то всё равно падало.