ripgrep의 musl 빌드가 초대형 검색에서 가끔 세그폴트 나는 이슈

• ripgrep 15.2.0의 x86_64 musl 바이너리가 초대형 검색에서 가끔 SIGSEGV로 죽는다는 이슈가 보고됨.

  • 대상 버전은 ripgrep 15.2.0, 리비전은 e89fff8.
  • 기능 플래그에는 PCRE2가 포함돼 있고, PCRE2 10.45와 JIT도 사용 가능하다고 보고됐어.

• 흥미로운 포인트는 이 문제가 특정 번들만의 문제가 아니라는 점임.

  • 최초 발견은 OpenAI Codex에 포함된 rg에서였어.
  • 그런데 그 바이너리가 공식 릴리스의 ripgrep-15.2.0-x86_64-unknown-linux-musl.tar.gz 안에 있는 바이너리와 바이트 단위로 동일했다고 함.
  • 제보자는 Codex 의존성 없이 공식 바이너리로도 독립 재현했다고 적었어.

• 재현 조건이 꽤 빡셈. 그냥 작은 레포에서 rg 몇 번 친다고 터지는 류는 아님.

  • 재현 스크립트는 원래 문제가 발생한 저장소의 통계를 흉내 내는 랜덤 파일 트리를 생성함.
  • 생성 결과는 약 20GiB 데이터, 약 180만 개 파일 규모.
  • 그 트리 루트에서 존재하지 않는 임의 문자열을 while 루프로 계속 검색하면 됨.

• 제보자 환경에서는 24코어 시스템에서 대략 1분 정도면 크래시가 났다고 해.

  • 검색 트리가 커널 블록 캐시에 들어갈 만큼 여유 RAM이 있는 상태였다고 함.
  • 즉 디스크 I/O로 느리게 막히는 상황보다, 많은 파일을 높은 동시성으로 빠르게 훑는 상황이 중요해 보임.

• 실제 동작은 코어덤프와 백트레이스가 남는 SIGSEGV.

  • 기대 동작은 너무 당연하게도 세그폴트가 나지 않는 것.
  • 검색 문자열이 트리에 없더라도 rg는 정상 종료해야지, 프로세스가 죽으면 안 됨.

• 이 이슈가 개발자에게 의미 있는 이유는 rg가 이제 사실상 개발 환경의 기본 인프라에 가깝기 때문임.

  • 에디터, 빌드 스크립트, 검색 UI, 코딩 에이전트가 모두 rg 같은 도구에 기대는 경우가 많아.
  • 초대형 모노레포나 생성 파일이 많은 워크스페이스에서는 '가끔 죽는 검색 도구'가 꽤 골치 아픈 장애가 될 수 있음.

---

기술 맥락

• 여기서 중요한 선택은 ripgrep을 어떤 libc 타깃으로 배포하고 실행하느냐예요. musl 빌드는 정적 링크와 배포 편의성이 좋아서 CLI 도구에서 자주 쓰이지만, 이번 이슈처럼 특정 allocator와 동시성 조건에서만 드러나는 문제가 생길 수 있어요.

• 재현 조건이 20GiB와 180만 파일이라는 점도 핵심이에요. 작은 테스트에서는 파일 열기와 디렉터리 순회가 충분히 압박받지 않지만, 이 정도 규모에서는 opendir, calloc, 스레드 스케줄링, 커널 캐시가 한꺼번에 빡세게 돌아가거든요.

• 백트레이스가 musl mallocng 내부를 가리킨다는 건 원인을 단정하긴 어렵지만 조사 방향은 분명해져요. ripgrep의 검색 패턴 처리, 디렉터리 순회 코드, musl의 메모리 할당기, 빌드 옵션을 함께 봐야 해요.

• 운영 관점에서는 공식 musl 바이너리를 그대로 쓰는 자동화 환경이 영향을 받을 수 있어요. 특히 코딩 에이전트나 대형 저장소 검색 파이프라인처럼 rg를 반복 호출하는 시스템에서는 드문 세그폴트도 사용자 경험을 망칠 수 있거든요.