Re[10]: Управление памятью в .NET для профессионалов
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.02.22 14:45
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А тут да, действительно автоматическая переменная. Вот только в C++ не было бы никакого new, и создавалась бы она на стеке, а там уничтожение автоматическое и гарантировано в известный момент, об этом и впрямь можно не очень думать. А если бы я хотел new, то пришлось бы в С++ либо Regex*, либо Regex& и delete. Далее см. мое предыдущее сообщение.
Павел, тут мышление С++ программистов никак не помогло бы и не помешало. Ну был бы у вас там new и delete — и дальше что?
Можно подумать, в вашем коде не бывает new и delete для локальных переменных.
Проблема-то — не в этом. Проблема — в том, что "вызов delete" на такой переменной освобождал не всю память.

На С++ запросто можно сделать такие же грабли — допустим, опция compiled будет динамически порождать исполняемый код, а вот освобождать она его почему-то не будет. VirtualAlloc будет делаться, а вот VirtualFree — нет.
Например, просто разработчик про это забыл. Не добавил этот VirtualFree в деструктор.
Или неправильно сделал подсчёт ссылок на исполняемый код при копировании regex.
Или вообще решил, что делать на каждый Regex отдельный VirtualAlloc — это оверкилл, и лучше сделать общую арену для динамического кода, которая будет освобождаться каким-то другим способом, не в момент вызова деструктора экземпляра regex.

В итоге — результат один: прикладной разработчик, не обладая глубокими знаниями о потрошках этого Regex, может получить точно такую же утечку. И точно так же он может её не заметить, если программа работает не 24*7.

То, как это было сделано в старом дотнете — не ошибка разработчика RegEx, а ограничение платформы.

Обсуждаемый вопрос — это что с этим делать. Вот у нас тут по соседству есть фанат точки зрения "не мои проблемы" — ну, течёт приложение и течёт. "Наверное, баг платформы".
Нам вот было интересно разобраться. Разбираться настолько глубоко, как в приведённых в топике книгах и картинках, не потребовалось, но понять, что вообще происходит — пришлось.
Ну, а после этого уже было очевидно, что можно сделать для решения проблемы.
А могло так оказаться, что реально найден баг в платформе. Тогда разборки дали бы возможность построить минимально воспроизводящий пример и отправить в Редмонд.
И так понятно, что никто в Редмонде не стал бы гонять наше приложение 72 часа под нагрузкой, чтобы найти причины утечки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.