LINUX.ORG.RU

Calloc нынче ни на что не влияет что-ли?

 ,


1

5

MWE:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef unsigned char u8;
typedef unsigned int  u32;

#define GB (1024ul * 1024ul * 1024ul)
#define TEST_SIZE (10)

int zerofy = 1;

static u8 * alloc(u32 size)
{
    u8 * res = calloc(size, 1);
    
    if (!res)
    {
        printf(" * Cannot alloc %u bytes\n", size);
        return NULL;
    }
    else
    {
        printf(" * Allocated %u bytes [%p]\n", size, res);
    }

    if (zerofy)
        memset(res, 0, size);

    return res;
}

static void rapemem(u32 zero)
{
    u32 i;
    u8 * p[TEST_SIZE];

    printf("Switching zerofy to %u\n", zero);
    zerofy = zero;

    for (i = 0; i < TEST_SIZE; i++)
        p[i] = alloc(GB);

    for (i = 0; i < TEST_SIZE; i++)
        free(p[i]);
}

int main(void)
{
    system("free -mh");
    printf("\n\n");

    rapemem(0);
    rapemem(1);
    rapemem(0);

    return 0;
}

Выхлоп:

alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ gcc -std=c89 poc.c 
alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ ./a.out 
              total        used        free      shared  buff/cache   available
Память:        7,6G        2,1G        4,2G        396M        1,2G        4,8G
Подкачка:          0B          0B          0B


Switching zerofy to 0
 * Allocated 1073741824 bytes [0x7fe248a9b010]
 * Allocated 1073741824 bytes [0x7fe208a9a010]
 * Allocated 1073741824 bytes [0x7fe1c8a99010]
 * Allocated 1073741824 bytes [0x7fe188a98010]
 * Allocated 1073741824 bytes [0x7fe148a97010]
 * Allocated 1073741824 bytes [0x7fe108a96010]
 * Allocated 1073741824 bytes [0x7fe0c8a95010]
 * Allocated 1073741824 bytes [0x7fe088a94010]
 * Allocated 1073741824 bytes [0x7fe048a93010]
 * Allocated 1073741824 bytes [0x7fe008a92010]
Switching zerofy to 1
 * Allocated 1073741824 bytes [0x7fe248a9b010]
 * Allocated 1073741824 bytes [0x7fe208a9a010]
 * Allocated 1073741824 bytes [0x7fe1c8a99010]
 * Allocated 1073741824 bytes [0x7fe188a98010]
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
Switching zerofy to 0
 * Allocated 1073741824 bytes [0x7fe248a9b010]
 * Allocated 1073741824 bytes [0x7fe208a9a010]
 * Allocated 1073741824 bytes [0x7fe1c8a99010]
 * Allocated 1073741824 bytes [0x7fe188a98010]
 * Allocated 1073741824 bytes [0x7fe143fff010]
 * Allocated 1073741824 bytes [0x7fe103ffe010]
 * Allocated 1073741824 bytes [0x7fe0c3ffd010]
 * Allocated 1073741824 bytes [0x7fe083ffc010]
 * Allocated 1073741824 bytes [0x7fe043ffb010]
 * Allocated 1073741824 bytes [0x7fe003ffa010]

WTF вообще? Теперь и calloc выделению доверять нельзя? Да здравствуют SIGSEGV без вариантов проверить выделение?

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

★★★★★

Последнее исправление: PPP328 (всего исправлений: 1)

calloc от этой херни был свободен так как занулял память.

Самостоятельно что ли? Зачем бы ему это делать, если система выделяет память обнулённую. Разве что если маленькими частями выделять.

xaizek ★★★★★
()
Ответ на: комментарий от PPP328

Всегда так было как только научились думать о безопасности, не? Я говорю о памяти, которая приходит от системы в результате sbrk или mmap, а не которая уже была в использовании этим приложением. Она же и приводит к оверкоммиту. Теоретически ядро может отдать ранее освобождённую страницу от этого же процесса, но оно так вроде не делает.

xaizek ★★★★★
()
Последнее исправление: xaizek (всего исправлений: 1)

Как страшно ЖЫТЬ! Я и не думал про то, что выделение больших объемов calloc'ом аналогично malloc'у!!! Блин, надо будет переделать свой макрос MALLOC, безопасно выделяющий память! Вместо calloc впихну туда malloc с memset.

anonymous
()
Ответ на: комментарий от PPP328

А в мане написано зануленная

       MAP_ANONYMOUS
              The mapping is not backed by any file; its contents  are  initialized  to
              zero.   The fd argument is ignored; however, some implementations require
              fd to be -1 if MAP_ANONYMOUS (or MAP_ANON)  is  specified,  and  portable
              applications  should  ensure  this.   The offset argument should be zero.
              The use of MAP_ANONYMOUS in conjunction with MAP_SHARED is  supported  on
              Linux only since kernel 2.4.
pftBest ★★★★
()

Ох уж эта борьба сишников с ОС...

enjoy your abstraction!

anonymous
()
Ответ на: комментарий от yoghurt

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

Т.е. На самом деле включение оверкоммита его выключает, а выключение - включает.

Вот так всегда. Рассуждает о банальностях, но таких банальностей не знаешь.

rustonelove
()
Ответ на: комментарий от anonymous

Эдик, мемсет тебе не поможет и я уже 20тысяч раз говорил почему. Тебе поможет только mmap + map_populate и ничего более.

Я и не думал про то, что выделение больших объемов calloc'ом аналогично malloc'у!!!

Это уже тысячи раз обсуждали и я не знаю куда вы смотрели.

rustonelove
()

Давай ещё больше сломаю твой шаблон.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>

typedef unsigned char u8;
typedef unsigned int  u32;

#define GB (1024ul * 1024ul * 1024ul)
#define TEST_SIZE (100)

int zerofy = 1;

static u8 * alloc(u32 size)
{
    u8 * res = calloc(size, 1);
    
    if (!res)
    {
        printf(" * Cannot alloc %u bytes\n", size);
        return NULL;
    }
    else
    {
        printf(" * Allocated %u bytes [%p]\n", size, res);
    }

    if (zerofy)
        memset(res, 0, size);

    return res;
}

static void rapemem(u32 zero)
{
    u32 i;
    u8 * p[TEST_SIZE];

    printf("Switching zerofy to %u\n", zero);
    zerofy = zero;
    
    uint64_t c = 0;;
    for (i = 0; i < TEST_SIZE; i++) {
        p[i] = alloc(GB);
        //немножечко уличной магии.
        for(uint64_t j = 0; j < GB; ++j) c += p[i][j];
    }
    
    fprintf(stderr, "%lu\n", c);
    for (i = 0; i < TEST_SIZE; i++)
        free(p[i]);
}

int main(void)
{
    system("free -mh");
    printf("\n\n");

    rapemem(0);
//     rapemem(1);
    rapemem(0);

    return 0;
}
rustonelove
()
Ответ на: комментарий от rustonelove

mmap + map_populate

Ну это уж совсем костыль получится... Но ладно, учту, что большие куски памяти можно только вручную mmap'ом выделять и не полагаться вообще на malloc/calloc.

Это уже тысячи раз обсуждали

Мимо ушей как-то пролетело.

anonymous
()

Как сложно жить, не читая документации. Что Эдику, что топикстартеру.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от rustonelove

Т.е. На самом деле включение оверкоммита его выключает, а выключение - включает.

Что я только что прочитал?

Deleted
()
Ответ на: комментарий от anonymous

Но ладно, учту, что большие куски памяти можно только вручную mmap'ом выделять и не полагаться вообще на malloc/calloc.

Не просто ммапом, ммап у тебя так же может отвалиться(на мемсете). Именно с map_populate.

rustonelove
()
Ответ на: комментарий от Deleted

Ну вот так. В ядре реализован механизм, который ничего не делает тогда, когда включен. Специально, чтобы юзерспейс-экспертам было проще после их 286-го.

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

Вот и повторяют этот миф от случая к случаю, а документация их путает.

rustonelove
()
Ответ на: комментарий от rustonelove

В ядре реализован механизм, который ничего не делает тогда, когда включен.

А включен он по умолчанию.

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

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

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

Deleted
()
Ответ на: комментарий от Deleted

А включен он по умолчанию.

Не включен. Включен он частично, да и из этого ничего не следует.

Я хз, что ты придумал, но оверкоммитом принято называть

Не принято. Оверкоммитом ошибочно называют механизм с аналогичным названием, который и наделяют источником подобных свойств «работы» памяти.

Что в современных никсах очень естественно, потому что ограничений памяти как таковых там нет, есть лишь хоровод страниц в NRU-списке, который ядро тасует туда-сюда между блочными устройствами и ОЗУ.

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

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

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

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

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

rustonelove
()
Ответ на: комментарий от rustonelove

Подобное поведения - это новшества 386

Ага, может еще и процессоры как таковые в Intel придумали?

Иначе этого не сделать - т.е. нельзя эмулировать прямое отображение.

Чего?

Deleted
()
Ответ на: комментарий от Deleted

Ага, может еще и процессоры как таковые в Intel придумали?

Никто ни о каких процессорах не говорил, об 386 говорилось в контексте сравнения его с 286, а именно интел взялся потому, что а) линукс был реализован под интел, б) 99.9% экспертов ничего кроме интела в глаза не видели. Сейчас, правда, появился арм, но это ничего не меняет. Всё это тянется с тех времён, когда их ещё не было, да и сейчас это просто игрушки.

Чего?

Я же ниже разобрал это. Вам непонятно что такое прямое отображение? Либо что?

rustonelove
()
Ответ на: комментарий от rustonelove

Вам непонятно что такое прямое отображение? Либо что?

Мне непонятно, зачем приплетать какой-то интел, если ни MMU не является экслюзивной разработкой интела, ни алгоритмы управления памятью в ядре не являются чем-то, присущим конкретно операционным системам для x86.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от post-factum

Те треды были про malloc, про него я не спорю. Но calloc же должен пройтись по всей памяти и занулить ее! Значит он маркирует ее как используемую. Так фиг там!

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Мне непонятно, зачем приплетать какой-то интел, если ни MMU не является экслюзивной разработкой интела, ни алгоритмы управления памятью в ядре не являются чем-то, присущим конкретно операционным системам для x86.

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

Т.е. х86 выступал в качестве примера. Ни и никак никакое mmu не выдавалось за эксклюзивную разработку интел. Вы это сами придумали.

Всё просто. Не надо придумывать того, чего там не было.

rustonelove
()
Ответ на: комментарий от PPP328

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

Те треды были про malloc

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

Но calloc же должен пройтись по всей памяти и занулить ее!

На mmap_threshold+ это не имеет смысла и это не делается.

Значит он маркирует ее как используемую.

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

В реальном мире очень много нюансов.

Так фиг там!

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

Всё было, но люди не слушали и верили в то, что у них есть какие-то свои решения.

rustonelove
()
Ответ на: комментарий от rustonelove

Ну дак и какое *оффициальное* (тм) решение-то? Работает архиважная утилита на узле где 600 метров памяти, скушала она 300, а при попытке записать получит SIGSEGV. Да тот же просмотрщик фотографий на локальном компьютере - вместо открытия сверхбольших фото просто вылет ,который даже создатели просмотрщика НЕ ИМЕЮТ ВОЗМОЖНОСТИ обработать. Тупо система построена так, что аллокация памяти непроверяема. Почему сделано такое говно?

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от PPP328

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

Deleted
()
Ответ на: комментарий от Deleted

И переписывать под реалтайм все окружение? Нет.

А причем здесь адаптивынй кэш? Делаете malloc для отображения, система дает память, пытаетесь заполнить данными от изображения - а там сегфолт. Повторю, почему сделано такое говно, которое нельзя проверить? Почему та же сраная шиндовс имеет аллокатор памяти, который может нормально сказать, что памяти нет.

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от PPP328

Куча всегда с говном выделяется!

Нетъ. Куча может выделяться с говном, если аллокатор переиспользует страницы, заюзанные ранее. А если ты просишь огромный зануленный сплошной блок, то единственный разумный подход - шарахнуть анонимный mmap и получить его от системы. Естестевенно в виртуальном состоянии.

Хочешь защититься от такой подлянки - записывай нули явно, memset'ом

annulen ★★★★★
()
Ответ на: комментарий от PPP328

И переписывать под реалтайм все окружение? Нет.

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

annulen ★★★★★
()
Ответ на: комментарий от PPP328

А причем здесь адаптивынй кэш?

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

Повторю, почему сделано такое говно, которое нельзя проверить?

Потому что память была на момент маллока, а потом кончилась?

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

Потому что гладиолус.

Выделите гиг анонимной памяти на машине с 2-мя гигами ОЗУ, сделайте 10 раз форк и попытайтесь каждым процессом эту память записать. И где теперь ваш бог?

а там сегфолт.

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

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

Deleted
()
Ответ на: комментарий от PPP328

Повторю, почему сделано такое говно, которое нельзя проверить?

Оверкоммит позволяет нехило экономить память.

annulen ★★★★★
()
Ответ на: комментарий от annulen

На чем? На том, что приложения будут рендомно отваливаться потому что они попросили 10 а им по факту дали 5 и при попытки записи в 6й блок SIGSEGV?

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

>А причем здесь адаптивынй кэш?

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

Да, а ничего, что это требует отдельного кода по ifdef на linux, bsd, windows, android и проч и проч, просто потому, что malloc без этого всратого оверкоммита всегда будет возвращать говноуказатели?

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

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

Так и что ж блджд оно по умолчанию не работает нормально? Почему для того, чтобы получить гарантированный блок памяти надо попердолиться?

Ах да,

Потому что гладиолус.

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от PPP328

Ну дак и какое *оффициальное* (тм) решение-то?

Надо понять суть проблемы. Вернее проблемы-то и нет на самом деле. Всё это( про механизмы работы памяти) уже десять раз разжевано.

Тупо система построена так, что аллокация памяти непроверяема.

Правильно, не система, а то апи, что даёт тебе libc. А почему? Потому что это апи из 70годов. Естественно оно никак не учитывает нюансы текущей реальности.

Почему сделано такое говно?

Всё очень просто. У тебя есть интерфейс, который строился тогда, когда память не обладала подобными свойствами. Даже на уровне системы апи( тот же посикс) не далеко ушел от libc-днища их 60х.

Именно поэтому и сделано такое говно, только ты его не там ищешь. Говно не память - говно предоставляемые тебе интерфейсы.

Если ты хочешь 100% получить память - ты можешь её получить mmap + map_populate. Я выше уже отвечал эдику. Тогда ты 100% получишь память, либо ошибку, если памяти не хватает.

rustonelove
()
Ответ на: комментарий от rustonelove

Правильно, не система, а то апи, что даёт тебе libc. А почему? Потому что это апи из 70годов. Естественно оно никак не учитывает нюансы текущей реальности.

Люльку на libc не гоните, а? У libc все правильно сделано:

malloc(N) - дать N байт памяти или вернуть NULL, если памяти не хватает.
Что сделали в ядре? Правильно, сказали нехер и стали всегда возвращать указатель на память, даже если ее нет.

Если ты хочешь 100% получить память - ты можешь её получить mmap + map_populate. Я выше уже отвечал эдику. Тогда ты 100% получишь память, либо ошибку, если памяти не хватает

Забавно, что под все остальные системы я просто могу использовать стандартный и простой в использовании malloc из libc, а для линукса нужно пердолиться для того, чтобы получить память. А полтом мне рассказывают, что malloc говно.

PPP328 ★★★★★
() автор топика
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от PPP328

Так и что ж блджд оно по умолчанию не работает нормально?

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

Почему для того, чтобы получить гарантированный блок памяти надо попердолиться?

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

А получить его можно. Ведь ты говоришь «от системы», а пользуешься не системным апи, а апи левого рантайма и от того все твои твои проблемы.

rustonelove
()
Ответ на: комментарий от PPP328

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

Linux — это не ОСРВ. У ней другая ниша и другие требования к разумному поведению в той непредсказуемой среде, где её запустят. Для системы общего назначения, применяемой в основном на серверах и иногда на рабочих станциях, эти умолчательные настройки оптимальны.

Если для вашей задачи они не оптимальны, маны по настройкам ядра вы знаете где найти. Linux конфигурируется в очень больших пределах. А если еще и рассмотреть вариант патчинга (выше тоже упоминалось) — то в огромных.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

Если какая-то программа не соблюдает интерфейсы - то это проблемы конкретного разработчика. Если она написал a = malloc(1000); a[5] = 34 без проверки на NULL - то это сугубо его проблемы. А вы таким говнокодеров поощряете, вместо того, чтобы дать по рукам!

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

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

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от PPP328

Люлька на libc не гоните, а? У libc все правильно сделано:

Нет, так это не работает.

Что сделали в ядре? Правильно, сказали нехер и стали всегда возвращать указатель на память, даже если ее нет.

Всё правильно сделали - убогий интерфейс из либ не в силах вместить в себя нюансы работы памяти.

Забавно, что под все остальные системы я просто могу использовать стандартный и простой в использовании malloc из libc

Сомневаюсь. Скорее тебя просто обманули с кастылём, который ты можешь врубить и в линуксе.

А т.к. ты не понимаешь того - что именно ты там тестируешь - ты и тестируешь не то, что нужно. sysctl vm.overcommit_memory=2 -w и у тебя отвалиться этот говнотест, но это ничего не меняет. Это не спасёт тебя от более сложных кейсов. Как и в других ОС.

Это типичная проблема, когда ты пытаешься желаемое выдать за действительное. Ты поверил в то, что всё нормально и тебе нормально. А то, что это нихрена не работает так, как ты ожидаешь - тебе и насрать.

А полтом мне рассказывают, что malloc говно.

Рассказывают те, кто что-то в теме понимают. А неадекватная реакция неосиляторов - мало кого волнует.

rustonelove
()
Ответ на: комментарий от PPP328

Даже хрен с математикой, krita, gimp, игры, kdenlive, и прочие и прочие обычные сраные десктопные приложения, которые едят много памяти- сидишь, никого не трогаешь, ХЕРАК - krita убита OOM киллером, потому что очередное поделие systemd потребовало новый блок памяти.

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от PPP328

Если какая-то программа не соблюдает интерфейсы - то это проблемы конкретного разработчика.

Косить под Ulrich-а Drepper-а не надо, он бы глупых вопросов на ЛОРе всё равно не задавал.

А вы таким говнокодеров поощряете, вместо того, чтобы дать по рукам!

Мало восклицательных знаков, надо больше.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от PPP328

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

Если ваша программа «обсчета какой-нибудь математической задачи» вышла за пределы ОЗУ, она уже ничего вам не обсчитает, потому что работа системы под интенсивным thrashing-ом замедляется даже не в разы, а на 2-3 порядка как минимум.

Вопрос надо предъявлять не ядру, а вам:

Почему вы запустили «обсчет важной математической задачи» не прикинув сначала требования по памяти и не подобрав нужное железо?

И почему вы не настроили систему так, чтобы она не убивала важный именно вам процесс?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от pftBest
        checking: bxi_bts_resize:(b1)[]
                                 (b1)[0x50, 0x75, 0x28, 0x02, 0x00, 0x00, 0x00, 0x00]
                                 (b1)[]
                                 (b1)[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

В первый раз обычный realloc, с 0 до 8, второй раз с занулением. Что-то в первом варианте я не вижу нулей.

PPP328 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Если ваша программа «обсчета какой-нибудь математической задачи» вышла за пределы ОЗУ

В том-то и дело, что вышла не она, а другой процесс. А прибили ее, как самую жрущую.

PPP328 ★★★★★
() автор топика

Сишечка - не язык ассемблера. Смирись. Она работает на абстрактной машине, которая довольно косвенно связана с железом.

dzidzitop ★★
()
Ответ на: комментарий от PPP328

В том-то и дело, что вышла не она, а другой процесс. А прибили ее, как самую жрущую.

И зачем вы запустили этот «другой процесс»?

Deleted
()
Ответ на: комментарий от PPP328

Если какая-то программа не соблюдает интерфейсы - то это проблемы конкретного разработчика. Если она написал a = malloc(1000); a[5] = 34 без проверки на NULL - то это сугубо его проблемы. А вы таким говнокодеров поощряете, вместо того, чтобы дать по рукам!

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

Люди, которые понимают то - как работает память - им не нужно проверять какие-то нулу/хренулы - для них память не рандомная херня и их преставления о памяти не ограничиваются «память бог».

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

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

Ты можешь сколь угодно долго верить в том, что проверил на null и уже не говнокод, но это не так. Это падающий говнокод, который работает лишь чисто случайно. Во что бы ты там не верил - это всегда будет так. Такие дела.

rustonelove
()
Ответ на: комментарий от PPP328

Упорное нежелание ни читать, ни думать.

И почему вы не настроили систему так, чтобы она не убивала важный именно вам процесс?

Это всё другой процесс виноват!!1111

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.