Является ли «нехватка памяти» исправимой ошибкой?

Я программировал долгое время, и программы, которые я вижу, когда им не хватает памяти, пытаются очистить и завершить работу, т.е. Я не могу вспомнить, когда в последний раз видел, как кто-то действительно пытался восстановиться и продолжить работу в обычном режиме.

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

Что является убедительным аргументом в пользу исправления ошибки?

75 голосов | спросил Walter Bright 2 TueEurope/Moscow2008-12-02T14:55:02+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 14:55:02 +0300 2008, 14:55:02

22 ответа


0

В библиотеке вы хотите эффективно скопировать файл. Когда вы делаете это, вы, как правило, обнаруживаете, что копирование с использованием небольшого количества больших чанков гораздо эффективнее, чем копирование множества меньших (скажем, быстрее скопировать файл размером 15 МБ, скопировав 15 кусков размером 1 МБ, чем копировать 15 000). 1K кусков).

Но код работает с любым размером чанка. Поэтому, хотя это может быть быстрее при использовании блоков размером 1 МБ, если вы разрабатываете систему, в которую копируется большое количество файлов, может быть целесообразно перехватить OutOfMemoryError и уменьшать размер фрагмента до тех пор, пока вы не добьетесь успеха.

Другое место - это кэш для объекта, хранящийся в базе данных. Вы хотите сохранить как можно больше объектов в кэше, но не хотите мешать остальной части приложения. Поскольку эти объекты могут быть воссозданы, это разумный способ сэкономить память, чтобы прикрепить кэш к обработчику нехватки памяти, чтобы отбрасывать записи, пока у остальной части приложения снова не будет достаточно места для дыхания.

Наконец, для манипулирования изображениями вы хотите загрузить как можно больше изображения в память. Опять же, OOM-обработчик позволяет вам реализовать это, не зная заранее, сколько памяти пользователь или ОС предоставит вашему коду.

[EDIT] Обратите внимание, что я работаю в предположении, что вы дали приложению фиксированный объем памяти, и этот объем меньше, чем общий объем доступной памяти, исключая пространство подкачки. Если вы можете выделить столько памяти, что часть ее должна быть заменена, некоторые мои комментарии больше не имеют смысла.

ответил Aaron Digulla 2 TueEurope/Moscow2008-12-02T15:16:20+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 15:16:20 +0300 2008, 15:16:20
0

Пользователям MATLAB все время не хватает памяти при выполнении арифметических операций с большими массивами. Например, если переменная x помещается в памяти и выполняется «x + 1», тогда MATLAB выделяет место для результата и затем заполняет его. Если при выделении происходит ошибка MATLAB, и пользователь может попробовать что-то еще. Было бы катастрофой, если бы MATLAB выходил всякий раз, когда появлялся этот вариант использования.

ответил 2 TueEurope/Moscow2008-12-02T19:08:36+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 19:08:36 +0300 2008, 19:08:36
0

OOM должен быть восстановим, потому что завершение работы - не единственная стратегия восстановления после OOM.

На самом деле существует довольно стандартное решение проблемы OOM на уровне приложений. При разработке приложения определите минимальный безопасный объем памяти, необходимый для восстановления из-за нехватки памяти. (Например, память, необходимая для автоматического сохранения документов, вызова диалоговых окон с предупреждениями, регистрации данных отключения).

В начале вашего приложения или в начале критического блока предварительно выделите этот объем памяти. Если вы обнаружите нехватку памяти, освободите защитную память и выполните восстановление. Стратегия все еще может потерпеть неудачу, но в целом дает большую отдачу.

Обратите внимание, что приложение не нужно закрывать. Он может отображать модальное диалоговое окно, пока условие OOM не будет разрешено.

Я не уверен на 100%, но я уверен, что ' Code Complete '(требуется чтение для любого уважаемого инженера-программиста) покрывает это.

P.S. Вы можете расширить свою прикладную среду, чтобы помочь с этой стратегией, но, пожалуйста, не реализуйте такую ​​политику в библиотеке (хорошие библиотеки не принимают глобальные решения без согласия приложений)

ответил Ifeanyi Echeruo 4 Jam1000000amSun, 04 Jan 2009 01:37:51 +030009 2009, 01:37:51
0

Я думаю, что, как и многие вещи, это анализ затрат и выгод. Вы можете запрограммировать попытки восстановления после сбоя malloc () - хотя это может быть сложно (ваш обработчик не должен допускать того же недостатка памяти, с которым он должен был справиться).

Вы уже отметили, что самым распространенным случаем является очистка и изящный сбой. В этом случае было решено, что стоимость прерывания изящно ниже, чем сочетание затрат на разработку и затрат на производительность при восстановлении.

Я уверен, что вы можете вспомнить свои собственные примеры ситуаций, когда прекращение программы является очень дорогим вариантом (машина жизнеобеспечения, управление космическим кораблем, долгосрочные и срочные финансовые расчеты и т. д.) - хотя первая строка Конечно, защита заключается в том, чтобы гарантировать, что программа имеет предсказуемое использование памяти и что ее может обеспечить среда.

ответил slim 2 TueEurope/Moscow2008-12-02T15:08:28+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 15:08:28 +0300 2008, 15:08:28
0

Я работаю над системой, которая выделяет память для кэша ввода-вывода для повышения производительности. Затем, обнаружив OOM, он забирает некоторую часть обратно, чтобы бизнес-логика могла продолжаться, даже если это означает меньший объем кэша ввода-вывода и немного более низкую производительность записи.

Я также работал со встроенными Java-приложениями, которые пытались управлять OOM, форсируя сборку мусора, опционально освобождая некоторые некритические объекты, такие как предварительно извлеченные или кэшированные данные.

Основные проблемы с обработкой OOM:

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

2) возможность освободить память. Это означает своего рода диспетчер ресурсов, который знает, какие объекты являются критическими, а какие нет, и система сможет повторно запросить освобожденные объекты, когда и если они позже станут критическими

Еще одна важная проблема - возможность откатиться, не вызывая еще одну ситуацию с OOM. Это то, что трудно контролировать на языках более высокого уровня.

Кроме того, базовая ОС должна вести себя предсказуемо в отношении OOM. Linux, например, не будет, если включена избыточная память. Многие системы с поддержкой подкачки умрут раньше, чем сообщат об OOM приложению-нарушителю.

И есть случай, когда не ваш процесс создал ситуацию, поэтому освобождение памяти не поможет, если нарушающий процесс продолжит течь.

Из-за всего этого, часто большие и встроенные системы используют эту технику, поскольку они имеют контроль над ОС и памятью, чтобы включить их, и дисциплиной /мотивацией для их реализации.

ответил n-alexander 2 TueEurope/Moscow2008-12-02T15:18:56+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 15:18:56 +0300 2008, 15:18:56
0

Его можно восстановить, только если вы поймаете его и будете правильно его обрабатывать.

В тех же случаях, например, запрос пытался выделить много памяти. Это вполне предсказуемо, и вы можете справиться с этим очень хорошо.

Однако во многих случаях в многопоточном приложении OOE также может происходить в фоновом потоке (в том числе созданном системной /сторонней библиотекой). Это почти невозможно предсказать, и вы не сможете восстановить состояние всех ваших потоков.

ответил Dennis C 2 TueEurope/Moscow2008-12-02T15:38:31+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 15:38:31 +0300 2008, 15:38:31
0

Нет. Ошибка нехватки памяти от GC, как правило, не может быть исправлена ​​внутри текущего потока. (Однако создание и завершение восстанавливаемого потока (пользователь или ядро) должно поддерживаться)

Что касается примеров счетчиков: в настоящее время я работаю над проектом на языке программирования D, который использует платформу NVIDIA CUDA для вычислений на GPU. Вместо того, чтобы вручную управлять памятью графического процессора, я создал прокси-объекты для использования DC. Поэтому, когда графический процессор возвращает ошибку «Недостаточно памяти», я запускаю полный сбор данных и выдаю исключение только в том случае, если во второй раз происходит сбой. Но на самом деле это не пример восстановления из памяти, это скорее интеграция с GC. Другими примерами восстановления (кэши, свободные списки, стеки /хэши без автоматического сжатия и т. Д.) Являются все структуры, которые имеют свои собственные методы сбора /сжатия памяти, которые отделены от ГХ и, как правило, не являются локальными для распределения. функция. Чтобы люди могли реализовать что-то вроде следующего:

T new2(T)( lazy T old_new ) {
    T obj;
    try{
        obj = old_new;
    }catch(OutOfMemoryException oome) {
        foreach(compact; Global_List_Of_Delegates_From_Compatible_Objects)
            compact();
        obj = old_new;
    }
    return obj;
}

Что является достойным аргументом для добавления поддержки регистрации /отмены регистрации самосборных /уплотняющих объектов для сборщиков мусора в целом.

ответил 2 TueEurope/Moscow2008-12-02T18:26:12+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 18:26:12 +0300 2008, 18:26:12
0

В общем случае это не подлежит восстановлению.

Однако, если ваша система включает некоторую форму динамического кэширования, обработчик нехватки памяти может часто выгружать самые старые элементы в кеш (или даже весь кеш).

Конечно, вы должны убедиться, что процесс «дампирования» не требует новых выделений памяти :) Кроме того, может быть сложно восстановить определенное выделение памяти, которое не удалось, если вы не можете напрямую подключить код сброса кеша на уровне распределителя, чтобы ошибка не распространялась до вызывающей стороны.

ответил Mike G. 2 TueEurope/Moscow2008-12-02T15:03:27+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 15:03:27 +0300 2008, 15:03:27
0

Это зависит от того, что вы подразумеваете под нехваткой памяти.

Когда в большинстве систем происходит сбой malloc(), это связано с тем, что вам не хватает адресного пространства.

Если большая часть этой памяти используется для кэширования или для областей mmap, вы можете восстановить часть этой памяти, освободив кэш или отключив его. Однако это действительно требует, чтобы вы знали, для чего вы используете эту память, и, как вы заметили, большинство программ этого не делают, или это не имеет значения.

Если вы использовали setrlimit() на себе (возможно, для защиты от непредвиденных атак, или, может быть, root сделал это с вами), вы можете ослабьте ограничение в вашем обработчике ошибок. Я делаю это очень часто - после запроса пользователя, если это возможно, и регистрации события.

С другой стороны, отлов переполнения стека немного сложнее и не переносим. Я написал подходящее решение для ECL и описал реализацию Windows, если вы идете по этому пути. Это было проверено в ECL несколько месяцев назад, но я могу выкопать оригинальные патчи, если вам интересно.

ответил geocar 2 TueEurope/Moscow2008-12-02T16:05:09+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 16:05:09 +0300 2008, 16:05:09
0

Особенно в средах со сборщиком мусора, вполне вероятно, что если вы поймете ошибку OutOfMemory на высоком уровне приложения, многие вещи выйдут за рамки и могут быть возвращены, чтобы вернуть вам память.

В случае однократного чрезмерного выделения приложение может продолжить работать без нареканий. Конечно, если у вас есть постепенная утечка памяти, вы просто столкнетесь с проблемой снова (скорее, скорее, чем позже), но все равно будет хорошей идеей дать приложению возможность элегантно завершить работу, сохранив несохраненные изменения в случай приложения с графическим интерфейсом и т. д.

ответил Michael Borgwardt 4 Jam1000000amSun, 04 Jan 2009 02:28:15 +030009 2009, 02:28:15
0

Да, OOM подлежит восстановлению. В качестве крайнего примера, операционные системы Unix и Windows довольно хорошо восстанавливаются в условиях OOM, в большинстве случаев. Приложения перестают работать, но ОС выживает (при условии, что памяти достаточно для правильной загрузки ОС в первую очередь).

Я приведу только этот пример, чтобы показать, что это можно сделать.

Проблема работы с OOM действительно зависит от вашей программы и среды.

Например, во многих случаях место, где происходит OOM, скорее всего, НЕ лучшее место для восстановления после состояния OOM.

Теперь пользовательский распределитель может работать как центральная точка в коде, который может обрабатывать OOM. Распределитель Java выполнит полный сборщик мусора до того, как он на самом деле вызовет исключение OOM.

Чем больше «осведомлен о приложении» ваш распределитель, тем лучше он будет использоваться в качестве центрального обработчика и агента восстановления для OOM. Снова используя Java, его распределитель не особенно осведомлен о приложении.

Это то, где что-то вроде Java легко разочаровывает. Вы не можете переопределить распределитель. Таким образом, хотя вы можете перехватывать исключения OOM в своем собственном коде, ничто не говорит о том, что какая-то используемая вами библиотека правильно перехватывает или даже правильно перебрасывает исключение OOM. Создать класс, который навсегда разрушен исключением OOM, тривиально, так как для некоторого объекта задано значение NULL и «этого никогда не случится», и его невозможно восстановить.

Так что, да, OOM можно восстановить, но это может быть ОЧЕНЬ сложно, особенно в современных средах, таких как Java и множество сторонних библиотек различного качества.

ответил Will Hartung 4 Jam1000000amSun, 04 Jan 2009 02:33:38 +030009 2009, 02:33:38
0

Вопрос помечен как «независимый от языка», но на него трудно ответить без учета языка и /или базовой системы. (Я вижу несколько хижин toher

Если выделение памяти является неявным, без механизма определения того, было ли данное выделение выполнено успешно или нет, то восстановление из состояния нехватки памяти может быть трудным или невозможным.

Например, если вы вызываете функцию, которая пытается выделить огромный массив, большинство языков просто не определяют поведение, если массив не может быть выделен. (В Ada это вызывает исключение Storage_Error, по крайней мере, в принципе, и это должно быть возможно обработать.)

С другой стороны, если у вас есть механизм, который пытается выделить память и может сообщить об ошибке, чтобы сделать это (как в C malloc() или C ++ new), тогда да, конечно, можно исправить после этой ошибки. По крайней мере, в случаях malloc() и new неудачное размещение не делает ничего, кроме сообщения о сбое (например, не повреждает внутренние структуры данных).

Имеет ли смысл попытаться восстановить, зависит от приложения. Если приложение просто не может быть успешным после сбоя выделения, то оно должно выполнить любую возможную очистку и завершить работу. Но если ошибка выделения означает лишь то, что одна конкретная задача не может быть выполнена, или если задача все еще может выполняться медленнее с меньшим объемом памяти, то имеет смысл продолжить работу.

Конкретный пример. Предположим, я использую текстовый редактор. Если я пытаюсь выполнить какую-либо операцию в редакторе, которая требует много памяти, и эта операция не может быть выполнена, я хочу, чтобы редактор сказал мне, что он не может выполнить то, что я просил, , и позволил мне продолжить редактирование . Завершение работы без сохранения моей работы было бы неприемлемым ответом. Сохранение моей работы и прекращение работы было бы лучше, но все равно излишне враждебно для пользователя.

ответил Keith Thompson 5 PM000000110000002631 2013, 23:02:26
0

Это сложный вопрос. На первый взгляд кажется, что отсутствие больше памяти означает «неудача», но вы также должны увидеть, что можно избавиться от многих вещей, связанных с памятью, если вы действительно настаиваете. Давайте просто возьмем неработающую функцию strtok, у которой, с одной стороны, нет проблем с памятью. Затем возьмите в качестве аналога g_string_split из библиотеки Glib, которая в значительной степени зависит от распределения памяти как почти все в программах, основанных на glib или GObject. Можно определенно сказать, что в более динамичных языках выделение памяти используется гораздо чаще, чем в более негибких языках, особенно в C. Но давайте посмотрим на альтернативы. Если вы просто завершаете программу, если у вас заканчивается память, даже тщательно разработанный код может перестать работать. Но если у вас есть исправимая ошибка, вы можете что-то с этим сделать. Таким образом, аргумент «сделать его восстанавливаемым» означает, что можно «по-разному» справляться с этой ситуацией (например, откладывать блок памяти на случай непредвиденных ситуаций или деградацию до менее объемной программы).

Итак, самая веская причина. Если вы предоставляете способ восстановления, вы можете попробовать восстановить, если у вас нет выбора, все зависит от того, всегда ли достаточно памяти ...

Привет

ответил Friedrich 2 TueEurope/Moscow2008-12-02T15:05:09+03:00Europe/Moscow12bEurope/MoscowTue, 02 Dec 2008 15:05:09 +0300 2008, 15:05:09
0

Это просто озадачивает меня сейчас.

На работе у нас есть пакет приложений, работающих вместе, и памяти не хватает. В то время как проблема заключается в том, чтобы заставить пакет приложений работать 64-битно (и, таким образом, иметь возможность работать за пределами 2 Go, которые есть у нас на обычной ОС Win32), и /или сократить использование памяти, эта проблема «Как выздороветь от ООМ "не уйдет из моей головы.

Конечно, у меня нет решения, но я все еще играю в поиске C ++ (в основном из-за RAII и исключений).

Возможно, процесс, который должен корректно восстанавливаться, должен прервать свою обработку в атомарных /откатных задачах (т. е. с использованием только функций /методов, дающих надежную /не исключительную гарантию исключений), при этом «буфер /пул памяти» зарезервирован для целей восстановления .

В случае сбоя одной из задач C ++ bad_alloc размотает стек, освободит часть памяти стека /кучи через RAII. После этого функция восстановления будет в максимально возможной степени спасать (сохранять исходные данные задачи на диске для последующего использования) и, возможно, регистрировать данные задачи для последующей попытки.

Я верю, что использование строгих /nothrow гарантий C ++ может помочь процессу выжить в условиях низкой доступной памяти, даже если это будет похоже на обмен памяти (т. е. медленный, несколько не отвечающий и т. д.), но, конечно, Это всего лишь теория. Мне просто нужно разобраться с предметом, прежде чем пытаться смоделировать это (то есть создать программу на C ++ с настраиваемым распределителем new /delete с ограниченной памятью, а затем попытаться выполнить некоторую работу в этих стрессовых условиях).

Ну ...

ответил paercebal 12 FriEurope/Moscow2008-12-12T00:35:45+03:00Europe/Moscow12bEurope/MoscowFri, 12 Dec 2008 00:35:45 +0300 2008, 00:35:45
0

Недостаточно памяти, как правило, означает, что вы должны выйти из того, что вы делали Если вы будете осторожны с очисткой, она может оставить саму программу в рабочем состоянии и сможет отвечать на другие запросы. Лучше, чтобы программа говорила: «Извините, недостаточно памяти для выполнения», чем «Извините, нехватка памяти, завершение работы».

ответил Loren Pechtel 4 Jam1000000amSun, 04 Jan 2009 02:35:41 +030009 2009, 02:35:41
0

Недостаточно памяти может быть вызвано либо истощением свободной памяти, либо попыткой выделить неоправданно большой блок (например, один гигабайт). В случаях «истощения» нехватка памяти является глобальной для системы и обычно затрагивает другие приложения и системные службы, и вся система может стать нестабильной, поэтому имеет смысл забыть и перезагрузиться. В случаях «неоправданно больших блоков» нехватка фактически не возникает, и безопасно продолжать. Проблема в том, что вы не можете автоматически определить, в каком случае вы находитесь. Поэтому безопаснее сделать ошибку невосстановимой и найти обходной путь для каждого случая, в котором вы столкнулись с этой ошибкой - заставить вашу программу использовать меньше памяти или в некоторых случаях просто исправить ошибки в коде, который вызывает выделение памяти.

ответил sharptooth 3 FebruaryEurope/MoscowbTue, 03 Feb 2009 11:06:09 +0300000000amTue, 03 Feb 2009 11:06:09 +030009 2009, 11:06:09
0

Здесь уже есть много хороших ответов. Но я хотел бы внести свой вклад с другой точки зрения.

Истощение практически любого повторно используемого ресурса в целом должно быть восстановлено. Причина заключается в том, что каждая часть программы в основном является подпрограммой. Тот факт, что одна подпрограмма не может завершить свою работу в данный момент, не означает, что все состояние программы является мусором. Тот факт, что на парковке полно автомобилей, еще не означает, что вы забрасываете машину. Либо вы ждете, пока стенд освободится, либо едете в магазин еще дальше, чтобы купить печенье.

В большинстве случаев есть альтернативный способ. Создание ошибки без возможности восстановления эффективно удаляет множество вариантов, и никто из нас не хочет, чтобы кто-то решал за нас, что мы можем и не можем делать.

То же самое относится и к дисковому пространству. Это действительно то же самое рассуждение. И вопреки вашей инсинуации о переполнении стека невозможно исправить, я бы сказал, что это и произвольное ограничение. Нет веских причин, по которым вы не должны иметь возможность генерировать исключение (выталкивать много кадров), а затем использовать другой менее эффективный подход для выполнения работы.

Мои два цента: -)

ответил Zuu 21 FebruaryEurope/MoscowbSat, 21 Feb 2009 22:26:26 +0300000000pmSat, 21 Feb 2009 22:26:26 +030009 2009, 22:26:26
0

Если у вас действительно не хватает памяти, вы обречены, так как больше ничего не можете освободить.

Если у вас недостаточно памяти, но что-то вроде сборщика мусора может запустить и освободить память, которую вы еще не умерли

Другая проблема - фрагментация. Хотя у вас может быть недостаточно памяти (фрагментировано), вы все равно не сможете выделить тот огромный кусок, который вам нужен.

ответил robert.berger 18 Maypm09 2009, 23:50:57
0

Я знаю, что вы просили аргументы за, но я вижу только аргументы против.

Я не вижу никакого способа добиться этого в многопоточном приложении. Как узнать, какой поток на самом деле отвечает за ошибку нехватки памяти? Один поток может постоянно выделять новую память и иметь gc-корни для 99% кучи, но первое неудачное выделение происходит в другом потоке.

Практический пример: всякий раз, когда я сталкивался с ошибкой OutOfMemoryError в нашем Java-приложении (работающем на сервере JBoss), это не значит, что один поток умирает, а остальная часть сервера продолжает работать: нет, есть несколько OOME, убивающих несколько потоки (некоторые из которых являются внутренними потоками JBoss). Я не понимаю, что я, как программист, мог бы сделать, чтобы оправиться от этого - или даже, что JBoss мог сделать, чтобы оправиться от этого. На самом деле, я даже не уверен, что вы МОЖЕТЕ: Javadoc для VirtualMachineError предполагает, что JVM может быть" сломана "после появления такой ошибки. Но, возможно, вопрос был более нацелен на языковой дизайн.

ответил waxwing 10 22009vEurope/Moscow11bEurope/MoscowTue, 10 Nov 2009 00:33:08 +0300 2009, 00:33:08
0

uClibc имеет внутренний статический буфер объемом 8 байтов или около того для файлового ввода-вывода, когда больше нет памяти для динамического распределения.

ответил Prof. Falken 13 Jpm1000000pmWed, 13 Jan 2010 18:31:16 +030010 2010, 18:31:16
0
  

Что является убедительным аргументом в пользу исправления ошибки?

В Java убедительный аргумент в пользу того, что не делает его исправимой ошибкой, заключается в том, что Java позволяет сигнализировать OOM в любое время, в том числе в тех случаях, когда результат может ваша программа перешла в несовместимое состояние. Поэтому надежное восстановление из OOM невозможно; если вы поймали исключение OOM, вы не можете полагаться ни на одно из состояний вашей программы. Увидеть Гарантия VirtualMachineError без бросков

ответил Raedwald 4 Jpm1000000pmWed, 04 Jan 2012 22:24:58 +040012 2012, 22:24:58
0

У меня есть это:

void *smalloc(size_t size) {
  void *mem = null; 
  for(;;) {
   mem = malloc(size);
   if(mem == NULL) {
    sleep(1);
   } else 
     break;
  }
  return mem;
}

Который уже несколько раз спас систему. То, что у вас недостаточно памяти, не означает, что какая-то другая часть системы или другие процессы, работающие в системе, имеют память, которую они скоро вернут. Лучше быть очень, очень осторожным, прежде чем пытаться делать подобные трюки, и иметь полный контроль над каждой памятью, выделяемой в вашей программе.

ответил nos 7 PM00000050000005731 2009, 17:40:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132