정말 반가운 소식임. 문제 해결에 참여한 모든 사람들에게 박수를 보냄
지난주에 이미 이 스레드에서 언급된 버그였음 Claude Code가 이 버그를 더 많은 사용자에게 노출시킨 계기가 된 것 같지만, 나처럼 Claude Code를 전혀 쓰지 않았는데도 같은 문제를 겪은 사람도 있었음
페이지가 ‘비표준(non-standard)’으로 분류되는 기준이 생각보다 흑백논리적이지 않음
또 scrollback-limit = 0 같은 설정을 쓴 사람들에게는 누수가 더 자주 발생했을 수도 있다고 생각함
수정된 방식이 불필요하게 비표준 페이지를 삭제 후 재생성할 수도 있어서, 이미 비표준인 오래된 페이지를 재활용할 수 있지 않았을까 하는 아쉬움이 있음
그 부분은 블로그 포스트에서 이미 다뤄졌음 PageList의 동작 방식은 예전부터 같았고, 버그가 있을 때도 용량 조정 중 잘못된 크기를 봤을 뿐임
성능 체감에는 변화가 없을 것임
제안한 대안도 고려했지만, 현재의 접근 방식이 벤치마크 데이터로 충분히 뒷받침되고 있음
나도 생각을 바꿀 여지는 있지만, 이번엔 세계관 자체를 바꾸기보단 누수 수정에 집중했음
베타 단계에서 이슈를 발견해 제보할 수 있었던 게 행운이었음
실제로 segfault를 유발하는 재현 가능한 버그였음
참고로, Claude Code 덕분에 CLI가 다시 매력적으로 느껴짐
지난 20년간 그 어떤 것보다 CLI를 새롭게 보이게 함
훌륭한 글이었음. mitchellh에게 Ghostty를 만들어줘서 감사함
작년에 전환했는데 후회한 적이 없음
다만 수정이 몇 달 뒤의 기능 릴리스에 포함된다는 게 조금 의외였음
버그 수정 릴리스에 포함될 줄 알았음
이미 최신 nightly build에 포함되어 있음
페이지 이야기가 나오자마자 “아, 메모리 풀링이구나” 싶었고, “링 버퍼겠네”라고 생각했는데 역시 scrollback 재사용이었음
버그 위치도 바로 짐작했음 — 페이지 메모리를 제대로 해제하지 않은 부분이었음
메모리 정렬 다이어그램도 멋졌음
새로운 시도를 할 때마다 누수 가능성이 생긴다는 걸 다시 상기하게 됨
이번 주에 Ghostty로 옮겼는데, 터미널 UI 앱 개발 중 OOM 크래시를 겪었음
탭바에 UTF8 아이콘을 쓰는 구조였는데, 터미널 크기 조정 시 바로 크래시가 발생했음
재현이 쉬워서 버그 리포트를 준비 중이었는데, 블로그 포스트에서 설명한 문제와 매우 유사해 보임
해결되길 기대 중임
@mitchellh에게 질문함 — 메모리 시각화는 어떤 도구로 만들었는지, 그리고 웹사이트가 모바일에서도 잘 작동하던데 스택 구성이 궁금함
Opus 4.5로 생성된 정적 HTML/CSS를 사용했음
시각화용 코드는 일회성이라 품질보다 정확성만 검증함
블로그 포스트별로 네임스페이스를 분리해 재사용하지 않음
구현이 이상한 짓(예: 비트코인 채굴, 비밀 유출 등)을 하지 않는지만 확인함
핵심은 정보 전달이며, 이런 다이어그램이 내용을 훨씬 이해하기 쉽게 만들어줌
Ghostty 개발을 계속 지켜보고 있음
약간의 오버엔지니어링 느낌이 있긴 하지만, 이런 버그 포스트모템은 장인정신을 사랑하는 사람에게 매우 가치 있는 자료임
어떤 면에서 오버엔지니어링이라고 느꼈는지 궁금함
Rust 기반 터미널이라면 이런 구현을 어떻게 성능 손실 없이 처리할지 궁금함
Ghostty나 터미널 에뮬레이터를 잘 모르는 입장에서도 이해하기 쉬운 글이었음
접근성이 높고 친절한 설명이 인상적이었음
재현 가능한 버그 리포트의 중요성을 다시 느꼈음
누군가 “Rust를 썼으면 이런 일은 없었을 것”이라고 말할 것 같아 기다리는 중임
오래 기다릴 듯함
Rust는 ‘메모리 누수 안전성(leak safety)’ 을 언어 차원에서 보장하지 않음
안전한 Rust 코드도 메모리를 누수시킬 수 있음 — 단, 이는 안전성 문제는 아님
표준 API에서도 Box::leak처럼 명시적으로 누수를 허용함
Rust는 단지 의도치 않은 누수를 만들기 어렵게 할 뿐, 완전히 막지는 않음
Hacker News 의견들
정말 반가운 소식임. 문제 해결에 참여한 모든 사람들에게 박수를 보냄
지난주에 이미 이 스레드에서 언급된 버그였음
Claude Code가 이 버그를 더 많은 사용자에게 노출시킨 계기가 된 것 같지만, 나처럼 Claude Code를 전혀 쓰지 않았는데도 같은 문제를 겪은 사람도 있었음
페이지가 ‘비표준(non-standard)’으로 분류되는 기준이 생각보다 흑백논리적이지 않음
또
scrollback-limit = 0같은 설정을 쓴 사람들에게는 누수가 더 자주 발생했을 수도 있다고 생각함수정된 방식이 불필요하게 비표준 페이지를 삭제 후 재생성할 수도 있어서, 이미 비표준인 오래된 페이지를 재활용할 수 있지 않았을까 하는 아쉬움이 있음
PageList의 동작 방식은 예전부터 같았고, 버그가 있을 때도 용량 조정 중 잘못된 크기를 봤을 뿐임
성능 체감에는 변화가 없을 것임
제안한 대안도 고려했지만, 현재의 접근 방식이 벤치마크 데이터로 충분히 뒷받침되고 있음
나도 생각을 바꿀 여지는 있지만, 이번엔 세계관 자체를 바꾸기보단 누수 수정에 집중했음
실제로 segfault를 유발하는 재현 가능한 버그였음
지난 20년간 그 어떤 것보다 CLI를 새롭게 보이게 함
훌륭한 글이었음. mitchellh에게 Ghostty를 만들어줘서 감사함
작년에 전환했는데 후회한 적이 없음
다만 수정이 몇 달 뒤의 기능 릴리스에 포함된다는 게 조금 의외였음
버그 수정 릴리스에 포함될 줄 알았음
페이지 이야기가 나오자마자 “아, 메모리 풀링이구나” 싶었고, “링 버퍼겠네”라고 생각했는데 역시 scrollback 재사용이었음
버그 위치도 바로 짐작했음 — 페이지 메모리를 제대로 해제하지 않은 부분이었음
메모리 정렬 다이어그램도 멋졌음
새로운 시도를 할 때마다 누수 가능성이 생긴다는 걸 다시 상기하게 됨
이번 주에 Ghostty로 옮겼는데, 터미널 UI 앱 개발 중 OOM 크래시를 겪었음
탭바에 UTF8 아이콘을 쓰는 구조였는데, 터미널 크기 조정 시 바로 크래시가 발생했음
재현이 쉬워서 버그 리포트를 준비 중이었는데, 블로그 포스트에서 설명한 문제와 매우 유사해 보임
해결되길 기대 중임
@mitchellh에게 질문함 — 메모리 시각화는 어떤 도구로 만들었는지, 그리고 웹사이트가 모바일에서도 잘 작동하던데 스택 구성이 궁금함
시각화용 코드는 일회성이라 품질보다 정확성만 검증함
블로그 포스트별로 네임스페이스를 분리해 재사용하지 않음
구현이 이상한 짓(예: 비트코인 채굴, 비밀 유출 등)을 하지 않는지만 확인함
핵심은 정보 전달이며, 이런 다이어그램이 내용을 훨씬 이해하기 쉽게 만들어줌
Ghostty 개발을 계속 지켜보고 있음
약간의 오버엔지니어링 느낌이 있긴 하지만, 이런 버그 포스트모템은 장인정신을 사랑하는 사람에게 매우 가치 있는 자료임
Rust 기반 터미널이라면 이런 구현을 어떻게 성능 손실 없이 처리할지 궁금함
Ghostty나 터미널 에뮬레이터를 잘 모르는 입장에서도 이해하기 쉬운 글이었음
접근성이 높고 친절한 설명이 인상적이었음
재현 가능한 버그 리포트의 중요성을 다시 느꼈음
누군가 “Rust를 썼으면 이런 일은 없었을 것”이라고 말할 것 같아 기다리는 중임
Rust는 ‘메모리 누수 안전성(leak safety)’ 을 언어 차원에서 보장하지 않음
안전한 Rust 코드도 메모리를 누수시킬 수 있음 — 단, 이는 안전성 문제는 아님
표준 API에서도 Box::leak처럼 명시적으로 누수를 허용함
Rust는 단지 의도치 않은 누수를 만들기 어렵게 할 뿐, 완전히 막지는 않음