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

[sergio]

Так, с нижеизложенным разобрались.
Вопрос сменился на: зачем ограничен размер стека, да еще и так низко?
Какой смысл ограничивать? (ну в теории понятно, что где-то есть граница между пространством стека и пулами фри мем, и однажды она может быть достигнута... в смысле - стек и фримем разростясь сойдутся в некой точке... но, гм, если ядро ограничивает стэк, то и за этой границей оно же надо понимать следит, и область стека тогда уж должна быть приложению гаранитирована-не-меньше, а не ограничена сверху? что я не понимаю?

Код: Выделить всё

  #define SIZE 209600000


  int main()  {

    int ii [SIZE];
    int i;
    for (i = 0;  SIZE != i;  ++ i)  ii [i] = i;

    return 0;
  }

Код: Выделить всё

$ gcc -Wall zz-memtest.c
$ ./a.out
Segmentation fault
$ gcc -Wall -O zz-memtest.c
$ ./a.out
$ gcc -Wall -O1 zz-memtest.c
$ ./a.out
$ gcc -Wall -O2 zz-memtest.c
$ ./a.out
$ gcc -Wall -O3 zz-memtest.c
$ ./a.out
$ gcc -Wall zz-memtest.c
$ ./a.out
Segmentation fault

теперь то же самое, но SIZE уменьшили на два порядка - 2096000

Код: Выделить всё

$ gcc -Wall zz-memtest.c
$ ./a.out

теперь SIZE увеличили на 1000 - 2097000

Код: Выделить всё

$ gcc -Wall zz-memtest.c
$ ./a.out
Segmentation fault
$ gcc -Wall -O zz-memtest.c
$ ./a.out
$

$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

[v04bvs]

int ii [SIZE];
выделяет sizeof(int) * SIZE байт на стеке. Размер стека очень ограничен и естественно кончается. Этот массив нужно выделять динамически (malloc).

[sergio]

int ii [SIZE];
выделяет sizeof(int) * SIZE байт на стеке. Размер стека очень ограничен и естественно кончается.

Эээ пардон, кем-чем он ограничен и как??? По какому принципу для компилируемого (или запускаемого) приложения устанавливается, что под стек страницы памяти мы не выделяем, а под хип выделяем???
И еще вопрос - segfault мы получаем при переполнении стэка или хипы? Или только при обращениях к несуществующей странице? - тут я темный....

Этот массив нужно выделять динамически (malloc).

Однако, можно видеть, что включении оптимизации система размещает на стеке массив на два порядка больший и уже приближающийся к объему оперативной памяти - и не пищит.

[Uncle_Theodore]

int ii [SIZE];
выделяет sizeof(int) * SIZE байт на стеке. Размер стека очень ограничен и естественно кончается.

Эээ пардон, кем-чем он ограничен и как???

Ядром, вестимо.
ulimit -s

Однако, можно видеть, что включении оптимизации система размещает на стеке массив на два порядка больший и уже приближающийся к объему оперативной памяти - и не пищит.

Я очень сомневаюсь, что при оптимизации масив такого размера размещается в стеке. Оптимизация либо делает что-то хитрое, либо нагло врет...

[Zeus]

Я очень сомневаюсь, что при оптимизации масив такого размера размещается в стеке. Оптимизация либо делает что-то хитрое, либо нагло врет...

Ага. Хитрое: смотрит, что прога нифига не делает - только память портит, и просто в _start'е сразу return ставит

Размер стека очень ограничен и естественно кончается.

Эээ пардон, кем-чем он ограничен и как???

Ядром, вестимо.

А компилятору (или компоновщику - кто там этим занимается) - разве нельзя параметром указать размер стека?

[sergio]

int ii [SIZE];
выделяет sizeof(int) * SIZE байт на стеке. Размер стека очень ограничен и естественно кончается.

Эээ пардон, кем-чем он ограничен и как???

Ядром, вестимо.
ulimit -s

Ага, 8М, все сходицо. Тогда у нас куда более интересный и полезный вопрос напрашивается: а зачем ограничен размер стека, да еще и так низко??? при том, что в остальном имеем по умолчанию

Код: Выделить всё

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

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

Однако, можно видеть, что включении оптимизации система размещает на стеке массив на два порядка больший и уже приближающийся к объему оперативной памяти - и не пищит.

Я очень сомневаюсь, что при оптимизации масив такого размера размещается в стеке. Оптимизация либо делает что-то хитрое, либо нагло врет...

Второе. ;D
Она его соптимизировала нафиг, как вот уже подсмотрел Zeus, и ничего при этом не сказала про "неиспользуемые переменные", не смотря на -Wall. ;D

Добавил вот это и получил сегфолт и при оптимизации, если размер больше 8М:

Код: Выделить всё

  #include <stdio.h>
  #define SIZE 20000000


  int main()  {

    int ii [SIZE];
    int i;
    for (i = 0;  SIZE != i;  ++ i)  ii [i] = i;

    printf("peek: %d\n", ii [5]);
/*
    for (i = 0;  i < SIZE;  i += SIZE / 20)  printf("at %d peek: %d\n", i, ii [i]);
*/
    return 0;
  }

А компилятору (или компоновщику - кто там этим занимается) - разве нельзя параметром указать размер стека?

Так было в ДОСе, наск я понимаю...

[Zeus]

А компилятору (или компоновщику - кто там этим занимается) - разве нельзя параметром указать размер стека?

Так было в ДОСе, наск я понимаю...

Понятно.
В Линухе я просто этим вопросом не озадачивался.
Последний раз когда я пытался запихать большой кусок данных в стек был как-раз когда я под ДОСом учился программить