golang은 다른 언어와 다르게 콜 스택 사이즈를 동적으로 할당해서 수 기가 바이트 단위까지 키운답니다. 코드에 문제가 있어 재귀 호출을 멈추지 못할 경우, 메모리를 다 잡아 먹어버리는데 오히려 stack overflow가 발생하는게 더 좋은거 아닌가요?
죽는건 같으니, 관점의 차이일거 같네요.
콜 스택 사이즈가 클 때보다, 작을 때가 코드 테스트 할 때 오류가 나는 경우를 찾기 쉽지않나요?
디버깅 관점이라면 메모리 오버플로우를 찾는게 쉽냐 잘못된 주소 참조를 찾는게 쉽냐인데 case by case 입니다. 콜스택사이즈가 늘어나건 뭘하건 어차피 마지막 죽은 위치부터 trace 하기때문에 그런 관점이라면 전 전자를 꼽겠습니다.
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
죽는건 같으니, 관점의 차이일거 같네요.
죽는건 같으니, 관점의 차이일거 같네요.
o_o
콜 스택 사이즈가 클 때보다, 작을 때가 코드 테스트 할 때 오류가 나는 경우를 찾기 쉽지않나요?
디버깅 관점이라면
디버깅 관점이라면
메모리 오버플로우를 찾는게 쉽냐 잘못된 주소 참조를 찾는게 쉽냐인데
case by case 입니다.
콜스택사이즈가 늘어나건 뭘하건 어차피 마지막 죽은 위치부터 trace 하기때문에
그런 관점이라면 전 전자를 꼽겠습니다.
댓글 달기