[질문] 왜 스택에는 크기 제한이 있음?

[익명(ninja75832)]

좁아터진 32비트 주소공간 쓰던 시절의 잔재인가? 그냥 커널로부터 1TB쯤 떨어진데부터 시작하면 스택에 따로 크기 제한이 있어야 할 이유는 없는거같은데 갑자기 궁금해지네

[익명(106.101)]

검색해보니까 몇 개 나오네
https://stackoverflow.com/questions/10482974/why-is-stack-memory-size-so-limited

[익명(ninja75832)]

대충 봤는데 명확한 이유가 있다기보단 걍 관습적인 이유거나 무한 재귀같은 에러 빠르게 찾기 위함 정도인가보네 ㄱㅅㄱㅅ

[익명(106.101)]

이걸 읽고 어떻게 그런 결론이 나오노? 기본값이 현재시점에 보기엔 작은 2MB나 1MB인 이유는 관습적이겠지만 니가 쓴 글에서 1TB 이따구로 안잡는 이유는 당연히 그런 식으로 잡으면 쓰레드나 함수마다 스택 잡으면 씹창나니까 그렇다고 써있는데

[익명(106.101)]

ㄴ이거 나 아님 나는 해석은 님 자유로 맡기겠음

[익명(220.79)]

병신인가 - dc App

[익명(ninja75832)]

욕하는건 상관 없는데 이유도 없이 욕하는 님이 더 병신 아닐까여?

[익명(220.79)]

스택 사이즈가 작은거랑 스택 사이즈에 제한이 있는거랑 두개가 의미하는바가 다른건 앎? - dc App

[익명(220.79)]

스택 무한성장 시켜서 커널나 다른 프로세스 메모리에 닿아도 되겠네 그럼 ㅇㅇ - dc App

[익명(220.79)]

걍 너같이 기초도 안된놈은 질문도 하면 안됨 ㅇㅇ - dc App

[익명(ninja75832)]

64비트 환경에서 총 VA가 16엑사바이트인건 알고 있나여? 대충 중간쯤에 100테라쯤 스택으로 잡고 메모리 레이아웃 짜도 되는건 아는데 이게 제한이 없는거랑 뭐가 다를까요? 그래서 32비트의 잔재냐고 물어본거고 다른 프로세스 메모리에 닿는다고 하는 님이 VA에 대한 기초 지식이 없는거 아닐까여?

[익명(ninja75832)]

텍스트 데이터 bss 힙 라이브러리 스택 커널 어드레스 스페이스 이렇게 생긴거 모르는 사람도 있나요... 다른 프로세스 공간으로 넘어간다는거 보니까 일단 님은 모르는듯?

[익명(220.79)]

그러니까 너가 병신이라는거임 ㅇㅇ 가상 주소도 결국 물리주소 부터 맵핑되어 있는거 모름? 뭐 니 생각에 수백테라쯤 되면 걍 퉁쳐도 된다 마인드임? 해킹하려고 하면 수백테라 걍 채워버리면 그만임 ㅇㅇ - dc App

[익명(ninja75832)]

ㅋㅋㅋㅋㅋ 페이지 스와핑 개념은 알고 얘기하시는건가여? 해킹 얘기가 왜나오져 뭐 어디서 어줍잖게 BOF 하나 줏어듣고 시부리시는거같은데 요즘 누가 스택 버그 남겨놓나여 다 힙에서나 터지지 이제 막 시프 듣는 학부생이신거같은데 어택랩이나 하러 가세여ㅎㅎ

[익명(ninja75832)]

백날천날 스택 확장시켜보세여 다른 프로세스에 닿나 페이지테이블을 다르게 관리하는데ㅋㅋ dos나 터지면 모를까

[익명(220.79)]

하 이 졷병신이 ㅋㅋ 그게 스택 사이즈에 제한이 있으니까 가능한거라고 애자련아 ㅋㅋ - dc App

[익명(123.254)]

이미 스택이 넘치는 상황을 고려해서 설계되어 있기 때문에, 커널은 스택보다 높은 주소에 배치됨 스택이 아무리 커진다 해도 커널 영역을 침범하는 건 불가능함. 프로세스끼리는 가상주소 방식 때문에 스택 터져도 서로 영향을 미칠 수 없음. 애초에 스택 넘치는 걸 방지하려고 스택 끝에 가드 페이지 하나 추가(스택 크기 제한)을 하고 있고. 가드 페이지가 없다고 가정하면 스택이 계속 자라서 힙이나 코드 영역 침범할 수 있기는 함 근데 코드는 쓰기 불가능해서 세그폴트 날꺼고 힙은 봉나상 문제가 있을수는 있겠지

[익명(211.52)]

애초에 64비트에서 총 VA가 16엑사바이트인거랑 스택의 크기 제한이랑 직접적으로 관련이 없는데 왜 애매하게 말하노… 진짜 궁금해서 물어본건지 키배를 뜨고 싶어서 떡밥을 던진건지ㅅㅂㅋㅋ 당연히 메모리주소야 2^64 까지 매핑되고 16엑사바이트부터 스택을 잡든 32엑사바이트부터 스택을 잡든 실제 피지컬메모리보다 더 많이 할당하면 당연히 터질껀데 어떻게 총 VA가 16엑사바이트라고 메모리 제한이 없는거랑 다를게 없다고 생각하노? 가상주소 매핑은 조상님이 대신해주나?

[익명(211.52)]

물리적인 메모리 크기에 제한이 있음 => 스택 메모리 크기에 제한이 있음 => 스택 시작 주소를 100테라바이트나 16엑사바이트에서 시작할 이유가 전혀 없음 이렇게 머리가 돌아가야 정상아닌가? 어떻게 VA가 16엑사바이트까지 매핑가능하니까 스택 크기를 무한히 잡아야 된다라는 발상이 나오지?

[익명(ninja75832)]

그니까 물리 메모리 제한때문에 OOM으로 죽일거면 힙처럼 걍 시작주소만 적당하게 세팅하고 굳이 시스템적인 제한을 둘 필요가 없는데 굳이 대부분의 컴파일러 구현은 1MB 제한을 두는 이유가 궁금했던거죠... 32비트면 최대 메모리 공간이 4GB니까 이 시스템이 말이 되는데 64비트면 주소공간 문제는 아닌거고

[익명(106.101)]

아이 ㅆㅂ~ 예를 들어 물리메모리가 16GB인 시스템을 생각해보자 운영체제가 메모리 가상화를 해주니까 16GB까지는 메모리를 프로세스마다 할당해줄수 있겠지? 그러면 동시에 10개의 프로세스 동작중인데 16GB까지 사용할 수 있게 되있다고 생각해보자. 얘들이 16gb를 꽉꽉 쓰기전까지는 아무 일이 안 일어나겠지만(1gb씩 할당 받아서 쓴다던지) 근데 10개의 프로세스가 16GB를 각자 전부 할당받아서 쓴다고 가정하면(제한이 없으니까, 운영체제가 항상 잡고있는 메모리는 무시한다 치고) 성능이 곧바로 씹창이 나겠지? 따라서 당연히 각각의 프로그램은 필요한 만큼만 메모리 공간을 제한해서 사용하는게 마땅함

[익명(ninja75832)]

맨 마지막 대댓으로 갈음하겠습니다. 당연히 시스템 피지컬 메모리가 꽉 찬 상황애서까지 죽이지 말고 놔둬야 한다고 주장하는 정신병자는 아닙니다.

[익명(106.101)]

극단적으로 피지컬메모리의 상한을 꽉꽉 채운 경우를 가정하긴 했지만 단순히 "시스템 피지컬 메모리를 넘지만 않으면 된다"가 아니라 생각없이 메모리를 잡으면 반드시 씹창이 날 위험이 있다는거임 코드의 모든 논리흐름과 메모리를 추적할 수 있는 개발자면 16엑사바이트 이지랄해도 되겠지만ㅇㅇ 아니 대체 VA 개념도 안잡혀서 protection, isolation도 제대로 모르는 사람도 직관적으로 아는 사실을 모름?

[익명(106.101)]

그런 식으로 대답할거 같더라ㅅㅂㅋㅋ 극단적으로 예를 들긴했지만 16기가바이트에 16기가바이트프로세스 10개가 아니가 16기가바이트 시스템에 1기가 프로세스 32개여도 씹창이 난다고 씨발럼아 지금 컴퓨터 켜서 프로세스 몇 개가 돌아가는지 그 프로세스안에 쓰레드가 몇 개일지 생각을 좀 쳐하고 씨발… 아 존나 답답하노

[익명(ninja75832)]

결국 님의 답은 스택은 deterministic하기 때문에 컴파일 타임에 그 크기를 결정할 수 있고 지나치게 큰 (>1mb) 스택 할당 자체가 애초에 일어나는게 이상한 상황이기때문에 잘못된 프로그래밍이여서 강제로 막아놨다 라는게 주장이군요. 처음부터 이렇게 썼으면 수긍할 만한 답인데 왜 욕부터 박았나요?

[익명(106.101)]

역설적으로 씨발 운영체제에서 메모리 가상화를 해주니까 필요한만큼 땡겨써야지… 운영체제가 프로세스들 메모리 사용량을 보면서 프로세스를 턱턱 죽이면서 동작할래? 주소공간이 넉넉하건 말건 당장 동작하는 프로세스들의 메모리 총합이 물리메모리 크기를 심각하게 초과하면 당연히 성능이 씹창이 나고 메모리가상화로 isolation를 보장하니까 각각의 프로세스는 다른 프로세스가 메모리를 얼마나 쓰는지 알 수 없고 그러니까 설계시에 필요한 만큼만 애초에 메모리를 잡아야되고 씨발~ 이걸 왜 설명해야 되지? 니말대로 VA도 제대로 모르는 친구도 아는걸?

[익명(ninja75832)]

주장이랑 별개로 제 개인적인 생각은 그럼에도 불구하고 자유를 주는게 낫다는 편입니다. 애초에 그렇게 병신같이 짤 사람이면 힙을 써도 똑같이 병신같이 짜기 때문에...

[익명(106.101)]

방금까지 욕한걸 살짝 후회했는데 욕먹어도 싸다 씨발 이건 주장이 아니라 현대 운영체제의 철학이나 설계개념에 가까운건데… 명시적/암시적으로 운영체제와 언어에 녹아있는거고 씨발 진짜 답답해 뒤지겠네

[익명(123.254)]

너무 싸우고 있길래 말하기 좀 그렇긴 한데 사실 스택 사이즈에 제한은 없음 당장에 리눅스만 봐도 setrlimit 호출하거나 프로세스 만들 때 스택 사이즈 맘대로 정할 수 있음. 기본으로 4mib든 8mib든 제한 두는 건 편의성 문제지 씹창 방지용은 아님 현대 OS는 사용자가 자기 컴을 씹창낼 자유를 보장한다

[익명(106.101)]

그리고 스택오버플로우 링크에도 나보다 더 친절히 설명되있는데 굳이 "One aspect that nobody has mentioned yet" 아무도 이부분에 대해선 설명안하길래~ 라고 적혀있는 error detection만 이해하고 가는 것도 어이없고ㅅㅂㅋㅋ 그냥 어그로라고 생각할련다

[익명(ninja75832)]

애초에 모던 언어는 힙 크게 할당해서 로지컬한 스택으로 쓰는거 아님? 실제 언어들 런타임 깊게 뜯어본적은 없는데 js 오브젝트들도 다 힙에 올라가있는걸텐데, 그럼 스택/힙 나눠서 생각한다는거자체가 C C++ 러스트같은 언매니지드 언어 쓰는 경우일거고 그럼 알아서 조심해야지...

[익명(123.254)]

나 스택 16GB 만들래요 하는 건 문제가 안됨 왜냐하면 운체단에서의 제한을 작은 메가바이트 단위에서 16GB로 늘렸을 뿐이거든 만들겠다고 선언한거 자체로는 실제로 물리 메모리 할당이 일어나지 않음 나중에 실제로 16GB를 사용해야 하는 일이 생긴다면 그때 물리 메모리가 잡히고 스왑이 되든 성능이 씹창이 나든 하겠지 그런데 언젠가 16GB가 실제로 필요할수도 있다는 사실은 바뀌지 않으니까 이런 걸 제한하진 않음 실수 방지용으로 작은 메가바이트 단위로 잡아놓는거지 사용자가 원할때는 제한 풀 수 있게 되어있음

[익명(106.101)]

하ㅆㅂ 고집 존나 쎄네 대체 이 코드가 메모리를 아무리 용을 써도 200MB 넘게는 안쓸거 같은데? 라고 생각하는데 사이즈는 16GB이따위로 잡을 이유가 없으니까 그렇게 안하는거지 가장 개발자 알아서 하게 냅두는 언어에서조차 그러는건 그럴만한 이유가 있다는거임 정확히는 제한을 안 걸 이유가 없다는거지… 개발자가 "알아서" 컴파일 시점에 사이즈를 세팅할 수 있으니까. 어느방향으로 생각해도 개발자 좆대로 할 수 있는건 매한가지임. 그러면 제한이라는거 자체를 아예 없앨 이유가 전혀 없는데?

[익명(ninja75832)]

좀 곱씹어 봤는데 안 걸 이유가 없다가 맞는 말 같네요. 걸 이유도 크리티컬한게 없긴 한데 프로그래머는 항상 병신짓을 하니. ㅇㅋ 님이 이김

[익명(123.254)]

나도 운체단에서 스택 사이즈 제한을 둬야 한다는 건 동의함 근데 그 이유가 커널닿기방지 피지컬메모리터지기방지 씹창방지 이거는 아니라는 거임 운체에서 기본으로 스택 사이즈 제한을 두는 건 일반적으로는 그거 이상으로 쓸 일이 없기 때문에, 사용자가 의도적으로 제한 푼 게 아니라면 버그일 확률이 매우 높기 때문임

[익명(123.254)]

106이 말한 것처럼 안 걸 이유가 없어서인거지 원한다면 ulimit -s unlimited 같은 명령으로 제한 풀 수 있음 물론 이 경우 무한재귀 있는 프로그램 돌 때 컴퓨터 맛감

[익명(123.254)]

요즘 운체는 메모리 관리 잘 해줘서 스택 사이즈 더 크게 잡는다고 램 꽉차고 하루종일 스왑하고 이런 문제는 없긴 함 보통은 지금 제한하고 있는 양으로도 쓸만하고 스택 더 필요하면 컴파일 옵션 같은거로 충분히 늘릴 수 있으니까 다들 큰 신경 안 쓰는듯

[익명(222.120)]

스택 사이즈가 무제한이면 힙메모리는 어따가 둘꺼임?

[익명(175.223)]

스택에 크기'제한'이 없으면 운영체제가 메모리 레이아웃을 설계할 수가 없는데 - dc App

[익명(ninja75832)]

힙은 크기 제한이 있나요?

[익명(106.101)]

당연히 제한이 있지 병신같은련아 힙이랑 스택이랑 방향이 반댄데

[익명(175.223)]

힙은 프로세스가 운영체제에 요청하면 (sbark같은 syscall) 새로 받아와서 링크드 리스트로 늘리는 식인가? 그랬음 malloc이 fail뜨면 제한에 닿은거임. 결국 제한은 있음. 스택은 애초에 프로세스 생성시에 사이즈가 결정 되어야만함. - dc App

[익명(ninja75832)]

malloc 구현에 따라 다른데 mmap으로 새 페이지를 받아올 때도 있고(musl) brk로 리밋만 늘릴때도 있죠(glibc). 결국 리밋에 닿는다 해도 죽지 않고 새로 메모리를 계속 받아오다 결국 커널이 oom으로 죽이는건데 스택은 growth를 계속 하다 특정 크기를 넘어가면 시스템에는 메모리가 충분한데도 죽어버립니다.

[익명(175.223)]

sbark가 아니라 sbrk ㅇㅇ. 스와핑도 결국 사이즈가 정해져야돼서 heap도 제한이 있는거라고 볼수있지 - dc App

[익명(ninja75832)]

그럴 이유가 있는지 궁금했던거고, 당연히 시스템 피지컬 메모리를 넘어갈 수는 없죠.

[익명(175.223)]

그니까 님이 말하는건 스택 사이즈가 작다 vs 스택사이즈가 무제한이어야 한다 이거중에 뭘 말하고 싶은거임? 스택사이즈는 결국 제한이 있어야됨. 님 원글은 '스택이 사이즈가 작다'가 아니라 스택 사이즈가 제한이 없어도 된다 라고 했잖음. - dc App

[익명(ninja75832)]

제한이 있는건 당연한데 컴파일러(혹은 커널)이 제한하는 이유가 없다고 생각합니다. 힙처럼 바운드 넘어갈때마다 pgfault 핸들러가 알아서 추가 할당을 해주면 될거같은데 굳이 기본 설정이 1 혹은 2MB고 넘기려면 추가적인 작업을 해줘야 하는 이유가 없다고 생각했던거고요

[익명(175.223)]

그럼 이제는 스택 크기 제한 있는건 ok인거고 사이즈가 작다로 방향을 튼건가요? 원문이 스택 크기 무제한론 이었으니까 이사단이 난듯. 스택 사이즈는 클 필요가 없다고 생각함. 이 내용은 맨 위에 스택오버플로 내용이 답변이 될듯?? - dc App

[익명(ninja75832)]

원문 개떡같이 쓴건 ㅇㅈ 근데 상식적으로 생각해보면 당연히 제한이라 하면 컴파일러에 의한 제한 말하는거 아닌가? 당연히 전체 피지컬 메모리에 의한 제한 + 주소공간 자체의 한계는 베이스로 깔고 들어가는거고 64비트는 후자가 없어졌는데도 굳이굳이 스택제한을 전체 공간에 비해 한없이 작게 유지하고 있으니까 문득 궁금해져서 쓴 글입니당

[익명(175.223)]

아니 님아 그런식으로 말할꺼면 원문에 1tb 이딴 소리 써놓으면 안되죠 이제와서 뭔 그게 당연한거 아닌가? 이럼 - dc App

[익명(175.223)]

갑자기 추해지시네ㅌㅋㅋ 원문 님이 읽어보세요. 따로 크기제한이 있을 필요는 없을거 같은데 이래놓고 무슨 ㅋㅋㅋ - dc App

[익명(ninja75832)]

글 쓸때는 스택 방향 거꾸로 생각했어서 커널로부터 1tb 운운한거같네여 스택이 계속 자라면 커널로 넘칠거라 생각했던듯ㅋㅋ 처음에는 스택에만 특별히 제한이 있고 힙이나 데이터 bss에는 제한이 없는게 궁금했어서 제목도 스택에'는'이라고 붙이긴 했는데 쓰다보니 점점 변명처럼 되가네여 더 추해지기 전에 도망치는게 나을듯

[익명(14.46)]

제한 있을 이유 없을 이유 둘 다 합리적이고 관습상 있는 쪽에 가까운 게 맞는 것 같은데 왜케 까이냐

[익명(39.7)]

댓글 읽다가 너무 별것도 아닌거 가지고 너무 싸운다 다들 ㅋㅋ 유닉스 리눅스는 스택크기를 환경변수로 지정해서 구동시킬수 있음 기본값 1~2메가 보다 훨 크게 구동 가능 , 글고 힙메모리 침범 이런거 뿐 아니라 멀티스레드 인것도 고려해야됨 스레드별로 스택 가지고 다님

[익명(39.7)]

댓글중에 컴파일러로 정한다는 댓글을 읽은거 같아서 구게아니라 운영체제 환경으로 바꿀수 있다는거 때문에 댓글달음

[익명(ninja75832)]

컴파일러도 관여함 컴파일러 설정보다 크게 스택할당하려고 하면 컴파일 에러 띄움 당장 gcc 가서 int a[100000000000] 하면 컴파일 안될걸 재귀가 너무 깊게 들어가서 콜스택 터지는게 커널단에서의 스택 크기 제한이고

[익명(222.120)]

ㄴ 그건 컴파일러가 머신마다 다르게 작동해서 그런거 아님?

[익명(106.101)]

보통 프로세스 하나에 할당되는 스택 메모리가 8MB인데 사실 이걸로도 충분하고, 안되면 쓰레드 추가해서 쓰면 되고 - dc App