Вход на сайт
Слегка охренел
181
NEW 26.05.05 17:27
В силу производственной необходимости ознакомился с man malloc :
...
By default, Linux follows an optimistic memory allocation
strategy. This means that when malloc() returns non-NULL
there is no guarantee that the memory really is available.
This is a really bad bug.
...
Очень удивился, что система вообще грузится.
---
Само плывет в pуки только то, что не тонет.
...
By default, Linux follows an optimistic memory allocation
strategy. This means that when malloc() returns non-NULL
there is no guarantee that the memory really is available.
This is a really bad bug.
...
Очень удивился, что система вообще грузится.
---
Само плывет в pуки только то, что не тонет.
30.05.05 13:01
This is a really bad bug.
ну исторически сложилось, что использование памяти должно быть учтено концептом. Речь ид╦т о виртуальной памяти процесса, резервированой под хип. реально представить, что хип может динамически расти. Но как только граници вирт. пространства памяти будут достигнуты -- процесс можно убрать, что и делается в этом случае. потому, если нет ошибок в концепте то по понятным причинам мэлок не должен бы возвращать ноль. такое решение однобокое, но:
1. Толку от этого ноля? Программа может при запуске опросить сколько адресного пространства дано ей в пользование. Один раз опросить и "калибрироваться" под эти рамки, вместо того, чтоб при каждом алокировании считаться с нол╦м. Естественно предположить, что прога, которая сожрала всю свою память, при получении нуля от мэлок основательно "перепашет" вс╦ то, что ей можно "перепахать".
2. прикинь сорцы програм, которые живут с тем, что мэлок периодически возвращает ноль. я в курсе, что возвращаемые значения нужно опрашивать, но речь ид╦т о том, что в основном програмят нормальные люди так, чтоб в случае возвращ╦нного нуля лишь ограничить обь╦м ущерба. при этом о функциональной части мало кто заботится(никто не заботится, это временами почти невозможно).
3. прикинь как трудно будет протестировать софт если он учитывает переполнение хипа?
--------------------
ну, хотел бы услышать(рад бы был) ещ╦ пару рассуждений.
~ semper idem ... ~
в ответ Russman 26.05.05 17:27
This is a really bad bug.
ну исторически сложилось, что использование памяти должно быть учтено концептом. Речь ид╦т о виртуальной памяти процесса, резервированой под хип. реально представить, что хип может динамически расти. Но как только граници вирт. пространства памяти будут достигнуты -- процесс можно убрать, что и делается в этом случае. потому, если нет ошибок в концепте то по понятным причинам мэлок не должен бы возвращать ноль. такое решение однобокое, но:
1. Толку от этого ноля? Программа может при запуске опросить сколько адресного пространства дано ей в пользование. Один раз опросить и "калибрироваться" под эти рамки, вместо того, чтоб при каждом алокировании считаться с нол╦м. Естественно предположить, что прога, которая сожрала всю свою память, при получении нуля от мэлок основательно "перепашет" вс╦ то, что ей можно "перепахать".
2. прикинь сорцы програм, которые живут с тем, что мэлок периодически возвращает ноль. я в курсе, что возвращаемые значения нужно опрашивать, но речь ид╦т о том, что в основном програмят нормальные люди так, чтоб в случае возвращ╦нного нуля лишь ограничить обь╦м ущерба. при этом о функциональной части мало кто заботится(никто не заботится, это временами почти невозможно).
3. прикинь как трудно будет протестировать софт если он учитывает переполнение хипа?
--------------------
ну, хотел бы услышать(рад бы был) ещ╦ пару рассуждений.
~ semper idem ... ~
~ semper idem ... ~
NEW 30.05.05 23:08
в ответ карлик_нос 30.05.05 13:01
Я не програмист, я каску на стройке нашел. Но в том небольшом количестве специальных прожек, в ккоторые я заглядывал. проверка выделения памяти всегда идет malloc(new), и в случае нулевого поинтера исполнение прерывается. Никаких проблем с исходниками и тестированием не замечено. А вот если маллок дает не нуль, но памяти свободной нет, то такие ошибки искать замаешься.
---
Хаб не поинт - пива не пpинесет
---
Хаб не поинт - пива не пpинесет
NEW 31.05.05 15:34
в ответ Russman 30.05.05 23:08
Не стоит расстраиваться, я ничего ни личного ни обидного не сказал.
В описание имелось ввиду, что мэлок либо возвращает указатель на память, либо процесс не возвращается из мэлока вообще. в самом мэлоке прцесс может подвиснуть в ожидании. Причины такого решения для многих систем очевидны, стоит только задуматься о причинах тех причинах по каким мэлок может возвратить ноль. думаю, что не стоит углубляться.
ессно проверять на ноль память нужно всегда. никогда не знаешь где будет этот код бегать.
~ semper idem ... ~
В описание имелось ввиду, что мэлок либо возвращает указатель на память, либо процесс не возвращается из мэлока вообще. в самом мэлоке прцесс может подвиснуть в ожидании. Причины такого решения для многих систем очевидны, стоит только задуматься о причинах тех причинах по каким мэлок может возвратить ноль. думаю, что не стоит углубляться.
ессно проверять на ноль память нужно всегда. никогда не знаешь где будет этот код бегать.
~ semper idem ... ~
~ semper idem ... ~
NEW 31.05.05 16:40
в ответ карлик_нос 31.05.05 15:34
> В описание имелось ввиду, что мэлок либо возвращает указатель на память, либо процесс не возвращается из мэлока вообще. в самом мэлоке прцесс может подвиснуть в ожидании.
Я указывал, вообще-то, на то, что согласно документации маллок может возвращать не нулевой указатель даже в случае, когда память на самом деле не свободна. Ты о чем-то другом говоришь.
---
Cocaine is nature's way of telling you you have too much money.
Я указывал, вообще-то, на то, что согласно документации маллок может возвращать не нулевой указатель даже в случае, когда память на самом деле не свободна. Ты о чем-то другом говоришь.
---
Cocaine is nature's way of telling you you have too much money.