Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Ошибка "Out of memory" [D7, WinXP]

Страницы: < 1 2
TrueCoder © (2005-06-01 03:29:00)
Так как Delphi пользуюсь нечасто, возникла проблема, решить которую сам пока не могу. Поиск тоже ничего что-то не дал..

Объявлен тип, например: type TValues = array [0..8] of Variant;
Объявлен массив: Values: array of TValues;

Имеется счетчик элементов массива Values = Count: Integer.
Изначально массив пуст, значит Count=0.
Новые элементы массива Values добавляются в цикле по одному через SetLength(Values,Count+1). И все работает, до тех пор пока размер памяти, занимаемый приложением, не достигает 128 мегабайт. После чего, возникает ошибка "Out of memory".
Причем, размер оперативки в компе - 1 Гб, не говоря уже о виртуальной памяти. В момент возникновения ошибки оперативки свободно около 500 Мб. Выгрузка вообще всех других приложений тоже не помогает.

Вопрос - отчего возникает такая ошибка? Может я чего не понимаю в механизме выделения памяти? В хелпе имеется такая фраза по SetLength - "If there is not enough memory available to reallocate the variable, SetLength raises an EOutOfMemory exception", что у меня, похоже, и происходит. Но почему?!

ОС - WinXP Home, сама Delphi - семерка. Благодарю за любую помощь.

ANB (2005-06-01 09:56:00) [21]
Без кода и поллитры не разберемся.

Mx (2005-06-01 09:55:00) [22]

> Думкин © (01.06.05 09:48) [13]

Вроде ошибка: Out of memory, а не Unable to Realloc? Не хватает, как я понял, объема, причем здесь количество реалокейтов?

Думкин (2005-06-01 09:48:00) [23]
> [12] Mx © (01.06.05 09:46)

хоть и реже вызываемые,- ты сказал(с)

Mx (2005-06-01 09:46:00) [24]
Возник вопрос: а чем же TList лучше? В не тоже есть Realloc'и, хоть и реже вызываемые, но в итоге точно также потребуется большой объем памяти (правда Pointer меньше чем Variant, но это лишь вопрос количества элементов).

ЮЮ (2005-06-01 09:32:00) [25]
Если человеку не нужны механизмы TList, то достаточно увеличивать длину массива так, как это сделано в TList.Grow, тем более, что количество действительных элементов массива он и так подсчитывает в Count

ANB (2005-06-01 09:32:00) [26]

> эта цифирь не имеет отношения к ВАП процесса
- согласен. Но не полностью. Чем больше эта цифра, тем больше вероятности нарваться на конец памяти. Приплюсовать сюда дефрагментацию . . . Кстати, автор не дал код и не сообщил максимальную длинну своего массива.

Digitman (2005-06-01 09:22:00) [27]

> ANB © (01.06.05 08:57) [3]

> Занято 128М

эта цифирь не имеет отношения к ВАП процесса

evvcom (2005-06-01 09:22:00) [28]
Вообще подход действительно неверный. Реаллокэйтить такие массивы - это встретиться с жуткими тормозами из-за постоянного копирования "полезной" информации. Лучше использовать TList или цепочки.

Bel (2005-06-01 09:21:00) [29]
Дык, массив то должен занимать непрерывный участок памяти. Памяти то может быть и 1.5Г свободно, а вот непрерывного участка размером, допустим, 10М может не быть. Поэтому в данном случае уже предложили решение - использовать TList.

ANB (2005-06-01 09:16:00) [30]

> Причем, учти, из них половина отдана под ядро
- Ну 2Г. Ну 500М накладные расходы (сроду столько не было). 1,5Г забить одним массивом ?
В принципе хороший совет - сначала определить максимальную длинну, а потом писать в массив, но он не всегда выполним. Например, я не всегда знаю заранее размер массива. В своем проекте у меня много мест, где длинна приращивается на 1, но на такую ошибку ни разу не нарывался. Ресурсы раз кончаться начали, но это я компонент кривой заюзал. Поменял на стандартный - ошибка ушла.

Bel (2005-06-01 09:09:00) [31]
> но у процесса 4Г адресного пространства

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

Anatoly Podgoretsky (2005-06-01 09:06:00) [32]
TrueCoder (01.06.05 03:29)
Где код?

ANB (2005-06-01 08:57:00) [33]

> Digitman © (01.06.05 08:45) [2]
Имхо. Очень странно. Занято 128М. Дефрагментация, понятно, но у процесса 4Г адресного пространства. Как может не хватить ? Может проблема в стеке ?

Digitman (2005-06-01 08:45:00) [34]
при очередном запросе Вorland Мemory Мanager'а на перераспределение памяти система не обнаружила в АП тек.процесса свободного региона затребованного размера и вернула отказ, о чем ВММ любезно и сообщил соотв.исключением

скорей всего АП процесса на момент отказа было сильно фрагментировано по причине предыдущих массированных "мелких" реаллокаций, инициированных вызовами SetLength()

Defunct (2005-06-01 04:35:00) [35]
Попробуйте заменить массив на TList, там SetLength используется немного не так как у вас.

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »