Comments 31
Главное проблема в 2021 это не физическая память , а пожирании виртуальной
Вот они твои оставшиеся 30
на самом деле смотреть надо сюда, это реальное использование памяти
Эта проблема терроризировала меня долго и была обнаружена в Windows 11 Dev сборке.
Количество виртуальной памяти ограничивается количеством реальной памяти + размером файла подкачки, скорее всего у тебя файл подкачки отключен. Попробуй выставить файл подкачки в автоматическом режиме и хорошенько освободить жесткий диск для файла подкачки без данных. Достаточно будет какого-нибудь даже медленного диска, просто чтобы система понимала, что, в случае отсутствия сжатия памяти, данные будет куда деть.
Я, на самом деле, на хабре статью об этом хотел написать, но посчитал, что не стоит того.
В 2019 такая проблема имеется?
Я сначала подумал, что в Visual Studio 2019 срабатывает какая-то защита, но всё оказалось немного интереснее.
Попробовал добавить XML'ку из статьи - поведение поначалу повторялось - GUI повис, Visual Studio начала отжирать память. На отметке ~3Гб GUI отвис, потребляемая память сбросилась примерно до 200Мб, но... потом снова начала расти. Примерно до 3Гб - сборс до 300Мб, 3Гб - 300Мб. Уже несколько циклов таких наблюдаю - всё не сдаётся, пытается распарсить.
Какая настойчивость, однако! :)
Может, это связано с каким-то компонентом? В 2019 он был 32-х битным, а в 2022 стал 64-битным.
— Сколько найдет, столько и занимает
(с) бородатый анекдот из 90ых.
Когда стало не хватать 10 Гб на машине Современного Программиста мне было уже очень стыдно. А тут уже сотня...
DOS
Чёрной пеленой экран заполнил чистый DOS.
Мышь
Потеряла форму, стала вдруг квадратной мышь.
Я разбил окно
Девяносто пятое, мастдайное окно
И поставил DOS, и тогда я понял
Это счастье - вот оно.
* * *
Слёзы на очках
Странные очки, а может слёзы на лице
DOS очистил всё, всё что было лишним
У меня на диске C:
Я нажал F8, и весёлый Norton
Удалял мне всё подряд -
Сорок мегабайт, может даже больше
Может даже шестьдесят.
* * *
И представил я
Город наводнился вдруг разумными людьми -
Вышли все под DOS!
А проклятый Windows
Удаляли, чёрт возьми!
Позабыв про Word
MS Excel, Corel Draw и прочий геморрой
Люди ставят DOS
Словно в рай заходят в DOS
Нормальный чистый DOS.
-----/ подписано в винампе как "DOS", DiBa, 2:5020/720.10 , From Fido with love :-) 1999 /-----
То есть если под досом запустить программу while(true) { malloc(1024); }, аналогичную ситуации в статье, то она, по вашему, не сожрёт всю доступную память только потому что она под досом?
Нет. Т.к. под DOS даже с XMS в защищенном режиме, доступно всего 4 GB (по факту - меньше).
Дело не в конкретном примере рекурсивного выделения памяти. А про деградацию. Количества эффективных полезных вычислений на такт процессора. Количества эффективных полезных занимаемых бит в ОЗУ. Или на винте.
- Давайте вот тут вместо явно ожидаемого простого цикла забубеним вызов модной функции которая в цикле внутри наколбечит нам нашу сахарную лямбда функцию, смотрите как красиво! Что, какой стек, какие CALL и RET, регистры, вы на каком языке разговариваете вообще?
- Давайте всё будет объект! И даже 1 и false тоже, всё. Это так круто. Да подумаешь для хранения одной буквы там на абстракциях съедается в сумме 308 байт, смешно, это же даже ещё не Кибибайт, о чём речь. Какой такой "чар", столица зергов чтоль? Унсигнед байт? Ой, уберите наркомана. Кстати нам потребуются ещё вот эти 148 npm пакетов. Только вон тот берите строго версии 1.4.17, а то ниже 1.14.2 у нас сзади бампер отваливается, а с 1.4.18 движок сквозь дно вылетает..
И вот это всё многослойным мыльным пузырём на пузыре оплетает сферы разработки везде - в коде, в IDE, на серверах, на сетевых потоках пакетов реквестов разной степени полезности. И вроде бы становится же лучше, удобней, даже бывает быстрее писать код и в целом что-то воплощать. Хотя от постоянной нынешней гонки средний процент костылей и неэффективных реализаций алгоритмов явно ползёт вверх. А копнёшь внутрь...
"Раньше было лучше" (с)
Мне непонятна проблема. Тут вполне ожидаемое поведение, все работает так, как должно работать. Вы же можете написать бесконечный цикл который жрет все ядра ЦПУ? Но вы не будете ругать студию, что она дает вам возможность написать такой код и даже его запускает?
Очевидно что программа с бесконечным циклом не запускается пока ты её не запустишь, а здесь ты просто импортировал файл, да и среда программирования тем более не должна зависать и потреблять бесконечно памяти при таких ошибках, а наоборот должна сообщать о них на этапе анализа, потому что программист всегда может случайно сделать такую ошибку, а с автоматически зависающей средой он очень долго будет её искать.
Вы же можете написать бесконечный цикл который жрет все ядра ЦПУ?
Если я просто напишу бесконечный цикл и не стану компилировать/запускать приложение, мне бы не хотелось, чтобы IDE сама попробовала его вычислить, начала жрать ресурсы и зависла . :)
Не было бы разговоров, если я бы я написал код, уязвимый к данной проблеме, запустил его и подал на вход соответствующий файл - окей, сам виноват.
Но здесь проблема однозначно на стороне IDE - нужно ограничивать такие операции. Собственно, я думаю факт, что в VS 2019 этой проблемы и не было и что MS фиксят этот баг в VS 2022, свидетельствует о том, что это именно не ожидаемое поведение.
А нафиг какой то кал вставлять в XML? Он даже не читабельный. Знаете любой уважающий себя студент-программист мог "повесить" программу ещё на первом курсе - сделав бесконечный цикл. Более того, ничего не умея удавалось случайно просто и не только сделать зависание программы, но и так что бы она вылетала (тогда был турбопаскаль). Тогда преподаватель ещё говорил что никогда такого раньше не видел, но сейчас я думаю, что он говорил не правду. Я конечно, больше по Java, но там написан какой то несвязный бред.Так что не пишите бред и да вижуал студио 64 битная есть уже давно, просто раньше был выбор между 32 битной и 64 битной, сейчас просто нет.
А нафиг какой то кал вставлять в XML?
Это же стандартная атака на систему.
Так что не пишите бред и да вижуал студио 64 битная есть уже давно
Пруф, пожалуйста.
https://habr.com/ru/company/yandex/blog/219311/#comment_7495221
qw1
15 апреля 2014 в 00:55
Задание с финала школьной олимпиады Китая 2018 года по хакерству:
— сгенерируйте предложение, на разбор которого парсер с указанной грамматикой потратит более 32ГБ памяти.
А нафиг какой то кал вставлять в XML? Он даже не читабельный.
Про это написано в статье:
Могут возникнуть 2 вопроса:
1. Зачем делать какие-то странные XML и добавлять их в проекты?
2. Что здесь вообще происходит?
Что ж, давайте разбираться...
Про Visual Studio.
да вижуал студио 64 битная есть уже давно, просто раньше был выбор между 32 битной и 64 битной
Нет, предыдущие выпуски Visual Studio (до 2022) - 32-битные.
Не думаю, но у них явно есть определённые проблемы в процедурой фидбека. Целая история была, про которую можно отдельную заметку писать.
Первое - нельзя оставить фидбек просто зарегистрировавшись на форуме (или я не понял, как). Нужно обязательно открыть Visual Studio, нажать там на соответствующую кнопку, после чего происходит редирект на сайт, где после авторизации можно оставить репорт. При том, что я был авторизован на сайте, при переходе на него через Visual Studio авторизация слетала, а залогиниться я не мог (не осталось скриншота ошибки).
В итоге после нескольких попыток всё-таки удалось. Оформил репорт, всё красиво выглядит, все есть - успокоился.
Вечером увидел опечатку в заголовке, решил поправить, но... не мог применить изменения из-за ошибки, указанной мной в комментариях. Пробовал несколько раз - безуспешно.
Окееей... оставил как есть. В итоге после первого комментария бота заголвок всё же был исправлен (я не понял, то ли со стороны MS, то ли с моей стороны как-то запрос на правки всё же прошёл), но... сломалась вся разметка. Картинки, списки, ссылки - всё превариталось в сплошное полотно текста.
Пытаюсь править - опять не даёт сохранить изменения. Несколько попыток - безуспешно. В итоге написал в комментариях о том, что всё сломалось, починить не удаётся.
Через какое-то время всё чинится само (или не само, вообще не понимаю, как там всё работает), но... из репорта пропадает сам XML-файл.
Пришлось зааттачить его в комментариях.
Целое приключение, в общем.
в clion есть ограничение:)
Вчера попробовал на релизной версии Visual Studio 2022. У меня 'отжор' остановился где-то на 6Гб. При наведении на XML-сущности выдаётся окошко со ссылкой. Жаль только, что щёлкнуть на неё вроде как нельзя. :)
В любом случае, ведёт она сюда. В общем, теперь самому можно задавать лимиты при обработке XML-документа.
Как Visual Studio 2022 съела 100 Гб памяти и при чём здесь XML бомбы?