Board.KolibriOS.org

Это спекулятивно оптимистичное поведение. Система позволяет программе зарезервировать из доступных адресов в userspace столько, сколько она просит. Физическая память выделяется после, страницами при обращении к адресам. Если в какой-то момент физической памяти не хватит, программа завершится со страничной ошибкой.

Кстати, винда тоже так делает, но у неё есть условно бездонный файл подкачки: не хватает — увеличивает.
Главный вопрос: в каких случаях программа берёт память и не использует её? Или конкретней: зачем нам этот баг эта сомнительная фича?

Pathoswithin
Практически во всех программах, сложнее "Hello, world!" Там, кстати, тоже. Например программа рисует клиентскую область в битмап, чтобы избежать ненужных перерисовок. Если этот битмап фиксированного размера под текущий размер окна, его надо будет пересоздавать при растягивании окна. В этом случае лучше зарезервировать под битмап буфер максимально необходимого размера и управлять страничной памятью вручную.

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

Да при чём здесь стек приложения?
Вот код с вершиной стека в нуле

ORG 0
BITS 32
; --------------------------- ;
MENUET01       db 'MENUET01'
version        dd 1
program.start  dd START
program.end    dd END
program.memory dd END
program.stack  dd 0
program.params dd 0
program.path   dd 0
; --------------------------- ;
START:
        mov    eax, 15
        mov    ebx, 3
        int    64
        mov    eax, -1
        int    64
; --------------------------- ;
END:

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

Pathoswithin
Система не может выделить памяти больше, чем есть. Просто не надо путать резервирование адресов в userspace процесса и физ. память всей системы.

Если я правильно понимаю, по адресам памяти от FFFFFFFFh и ниже проецируется видеобуфер и доступ туда открыт всем программам.

Serge
Я не путаю, я спрашиваю проверяет ли система количество свободной физической памяти в момент резервирования адресов в userspace процесса?

Pathoswithin
Нет, не проверяет. Это лишнее. Некоторые применения 68.12 не требуют немедленного выделения физической памяти. Например открытие расшаренной памяти, загрузка длл, маппинг текстуры в драйвере. Широко применяемая malloc традиционно запрашивает память блоками большого размера при этом реально может использоваться 10%. Под стек в приложениях (binutils, Fplay и все остальные с newlib) резервируется 2Mб и т.д.

А если нет

General protection fault это не page fault. Попробуй FFFFFFF8h.

Вот возьми сам и попробуй. Тебе полезно будет. А я результат знаю.

Serge, ты так и не сказал, как можно решить эту проблему. Посмотри ещё раз на картинку в посте viewtopic.php?f=2&t=684&start=930#p57580 и скажи, как нужно в этом случае действовать приложению, чтобы не нарваться на PageFault. Ведь, как видно, памяти выделено явно больше, чем имеется, только приложения об этом не знают. Если можно, то пример кода, как можно обойти такую проблему.

А если f18.16(получить размер свободной оперативной памяти)?

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

Да, 18.16 единственный вариант.

Я не очень понимаю, как это должно помочь. Конкретно в приведённом мной примере на скриншоте показано, что свободно 206 из 255 мегабайт. Ну и не забываем, что система многозадачная — пока наш процесс делал запрос, другой процесс уже взял и использует память.
А лучше привести пример кода, конечно