определить иницилизированый указатель

[Croessmah]

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

Я уже добрался.
Система Ubuntu 16.04.
Код:

#include <iostream>
#include <cstdint>
#include <cstring>




int main()
{
	uint64_t size = 1000000000u;
	uint64_t c = 0;
	while (c < 2000u) {
		try {
			uint64_t *p = new uint64_t[size];
			std::cout << (++c) << " " << p << std::endl;
			memset(p, 0, size*sizeof(*p));
		} catch (...) {
			std::cout << "exception" << std::endl;
			break;
		}
	}
}

vm.overcommit_memory = 0.
Получаем exception.

При vm.overcommit_memory = 1
система тупо убивает процесс. Получаем killed.

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

[Croessmah]

И вот видео с результатом: https://youtu.be/8cM2kNbFcNg

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

В нашем случае роль сыграла политика overcommit_always.
Всего лишь одна циферка в параметрах системы убила приложение,
вместо ожидаемого вылета исключения из new-expression.

Думаю, на этом спор окончен. Пойду ставить политику как было.

[olej.tsil]

Сообщение от Croessmah

И вот видео с результатом:

Даже смотреть не стал ... не интересно, потому что логика происходящего и так понятна.

Сообщение от Croessmah

При vm.overcommit_memory = 1
система тупо убивает процесс. Получаем killed.

Испортить руками можно всё! ... если сильно постараться...
Можно ещё поиграться с распределителем памяти в ядре, например, ... поменять slub-алокатор на slab-алокатор, а затем на slob-алокатор ... и с огромным интересом наблюдать что там происходит.

Вот что пишут в обсуждениях в документации Linux ... по поводу политики:

Going in the right direction

Since 2.5.30 the values are: 0 (default): as before: guess about how much overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise about the overcommit - never commit a virtual address space larger than swap space plus a fraction overcommit_ratio of the physical memory.

Как вы понимаете, в нормальных Linux (Fedora etc.) по умолчанию установлена политика в 0, когда выделение памяти контролируется. И только в некоторых ... "рыночно озабоченных" Linux (Ubuntu etc.) они могут поставить политику и в 1 - для визуально кажущейся более быстрой загрузки системы (и она действительно при этом быстрее!).

Сообщение от Croessmah

Думаю, на этом спор окончен.

Спор здесь и не интересен, и неуместен.
Меня, лично, во всём этом интересуют вовсе не академические и высоко научные обсуждения ... и уж тем более, не всякие "глубинные аспекты", выдумываемые ВУЗ-овскими пЫдагогами для задрачивания студентов, а исключительно (для себя) то, можно ли в реальных проектах контролировать успешность выделения памяти.

[pompiduskus]

Сообщение от olej.tsil

Даже смотреть не стал ... не интересно, потому что логика происходящего и так понятна.

После это фразы, дамаю с тобой вообще не о чем больше говорить!

[waleri]

Сообщение от Croessmah

При vm.overcommit_memory = 1
система тупо убивает процесс. Получаем killed.

К языку С/С++ это не имеет отношения.
Если ОС подсовывает мусор приложение мало что может сделать.
new либо выделяет память, либо бросает exception, либо возвращает 0.
Мне, кроме всего прочего, интересно как это все работает - ведь new/malloc сами обращаются к выделенному блоку - почему не вылетает тогда?

[olej.tsil]

Сообщение от pompiduskus

После это фразы, дамаю с тобой вообще не о чем больше говорить!

Так тебя здесь и не было ... с тобой никто и не собирался "говорить".

Мужчина, вас здесь не стояло - проходите.

[olej.tsil]

Сообщение от waleri

new либо выделяет память, либо бросает exception, либо возвращает 0.
Мне, кроме всего прочего, интересно как это все работает - ведь new/malloc сами обращаются к выделенному блоку - почему не вылетает тогда?

По стандарту new вовсе не обязан возвращать NULL, это всё осталось за malloc() и т.п.
А политики выделения памяти (если ними играться) как-раз к malloc() и относятся, и он точно так же будет вылетать.
Естественно, что new никакого выделения памяти вообще не производит, он а). сначала вызывает именно malloc(), а затем б). в выделенной в п.а памяти выполняет конструктор объекта.

[Croessmah]

Мне, кроме всего прочего, интересно как это все работает - ведь new/malloc сами обращаются к выделенному блоку - почему не вылетает тогда?

В том-то и дело, что участок памяти не инициализируется, поэтому
внутри new-expression никакого обращения к этой памяти не происходит.

Если ОС подсовывает мусор приложение мало что может сделать.

Ну дык я изначально об этом и толкую, что new не всё контролирует.

new либо выделяет память, либо бросает exception, либо возвращает 0.

new-expression кидает исключение, но есть версия, которая не кидает:

new (std::nothrow) SomeType();

в данном случае, new-expression будет вызывать

void* operator new (std::size_t size, const std::nothrow_t& nothrow_value) noexcept;

Мы можем передавать и свои параметры в этих "скобочках" в new-expression.

Сообщение от olej.tsil

сначала вызывает именно malloc()

Как устроен new-expression зависит от реализации, но
new-expression по стандарту использует operator new, и operator new[], а не malloc.
А как устроены operator new/operator new[] - фактор совершенно монописуальный.

По стандарту new вовсе не обязан возвращать NULL

Зависит от используемой версии new-expression.

[olej.tsil]

Сообщение от Croessmah

Зависит от используемой версии new-expression.

Да, но именно поэтому стандарт и говорит, что new не обязан возвращать NULL, и дефаултные реализации этого и не делают, и на это никогда нельзя рассчитывать.

Вот C-шные API: malloc(), calloc() etc., в противоположность, обязаны возвращать NULL при невозможности выделить память.

[Croessmah]

но именно поэтому стандарт и говорит, что new не обязан возвращать NULL

Еще раз:

Type *p = new Type;
//Вылетит исключение std::bad_alloc, 
//если обнаружится факт неудачного выделения памяти. 
//Ни о каком возврате nullptr речи не идет.

Type *p = new (std::nothrow) Type;
//Вернет nullptr, если обнаружится факт неудачного выделения памяти.
//Исключение может вылететь только из конструктора Type, 
//посему абсолютно бесполезен для non-pod типов.

Вот C-шные API: malloc(), calloc() etc., в противоположность, обязаны

Они ну никак не могли кинуть исключение, потому как в C их и нет.