address-sanitizer

address-sanitizer 스킬 개요

address-sanitizer는 어떤 용도인가

address-sanitizer 스킬은 테스트, 특히 퍼징과 크래시 트리아지 과정에서 AddressSanitizer(ASan)를 활용해 메모리 안전 버그를 잡는 데 도움을 줍니다. “어딘가에서 메모리가 깨지고 있다”는 막연한 문제를 재현 가능한 스택 트레이스, 할당 이력, 또는 실패하는 테스트 케이스로 바꿔야 할 때 가장 유용합니다.

가장 잘 맞는 사용자와 사용 사례

이 address-sanitizer 스킬은 C/C++ 테스트 워크플로, 퍼징 파이프라인, 그리고 unsafe를 사용하는 Rust 코드에 특히 잘 맞습니다. 더 깊은 수동 분석으로 넘기기 전에 실무적으로 쓸 수 있는 address-sanitizer for Security Audit 경로가 필요한 보안 리뷰어에게도 유용합니다.

무엇이 다른가

ASan은 일반적인 프롬프트 트릭이 아니라, 컴파일 시점 계측과 런타임 트레이드오프를 함께 다루는 워크플로입니다. address-sanitizer 스킬의 핵심 가치는 ASan이 적절한 도구인지, 어떤 입력이 필요한지, 그리고 빌드·플래그·환경 불일치로 인해 잘못된 결과가 나오는 일을 어떻게 피할지 판단하도록 도와준다는 데 있습니다.

address-sanitizer 스킬 사용 방법

스킬 설치하기

스킬 러너가 기대하는 저장소 설치 흐름을 따라 설치한 뒤, 스킬 번들에서 SKILL.md를 열어 address-sanitizer install이 성공했는지 확인하세요. 환경이 스킬 매니페스트를 지원한다면, 프롬프트 라우터가 올바른 안내를 트리거할 수 있도록 이름이 정확히 address-sanitizer인지도 확인해야 합니다.

올바른 테스트 컨텍스트를 전달하기

좋은 address-sanitizer usage는 구체적인 대상에서 시작합니다. 언어, 빌드 시스템, 테스트 명령, 크래시 증상, 그리고 퍼징 중인지, 유닛 테스트를 돌리는 중인지, 아니면 이슈를 재현하는 중인지까지 함께 적어 주세요. “ASan 쓰는 법 알려줘”보다 “CMake로 빌드한 C++ 라이브러리에서 퍼즈 타깃이 크래시가 나는데, ASan 플래그와 최소 재현 워크플로가 필요하다”처럼 쓰는 편이 훨씬 유용합니다.

이 순서로 스킬 파일을 읽으세요

먼저 SKILL.md부터 보고, 이어서 환경에서 제공하는 연결된 저장소 नोट나 보조 문서를 확인하세요. 이 저장소 경로에서는 먼저 핵심 가이드를 찾고, 그다음 개요, 핵심 개념, 적용 시점, 빠른 참고 순으로 읽어야 빌드 플래그를 수정하기 전에 운영 제약을 제대로 이해할 수 있습니다.

대략적인 목표를 실사용 가능한 프롬프트로 바꾸기

최대한 좋은 결과를 얻으려면, 무엇을 입증하려는지, 어떤 컴파일러와 테스트 하네스를 쓰는지, 성공 기준이 무엇인지 알려 주세요. 예를 들어: “Clang으로 빌드한 Linux C++ 서비스에서 heap-use-after-free를 찾고 싶습니다. ASan 빌드 플래그, 런타임 옵션, 그리고 퍼징 실행에서 나온 크래시를 가장 짧게 트리아지하는 방법을 알려 주세요.” 이런 식의 프레이밍이 일반적인 설명을 요청하는 것보다 더 나은 address-sanitizer guide 결과를 만듭니다.

address-sanitizer 스킬 FAQ

address-sanitizer는 퍼징 전용인가요?

아닙니다. 퍼징이 흔한 사용 사례이긴 하지만, address-sanitizer 스킬은 메모리 손상을 의심하는 유닛 테스트, 회귀 테스트, 크래시 디버깅에도 적용됩니다. 이미 재현 가능한 버그라면 ASan은 더 명확한 스택 트레이스를 얻는 가장 빠른 경로가 될 수 있습니다.

언제 쓰지 말아야 하나요?

프로덕션과 비슷한 성능이 필요할 때, 대상 플랫폼이나 툴체인이 이를 잘 지원하지 않을 때, 또는 버그가 메모리 안전성과 무관할 가능성이 클 때는 ASan을 먼저 선택하지 마세요. 문제가 논리 오류, 프로토콜 수준, 성능 문제라면 ASan은 대체로 신호보다 잡음을 더 많이 만듭니다.

일반 프롬프트보다 나은가요?

메모리 오류 탐지와 트리아지가 목적이라면 그렇습니다. 일반 프롬프트도 ASan 개념을 설명할 수는 있지만, address-sanitizer 스킬은 플래그, 입력, 디버그 단계를 덜 시행착오적으로 고르게 해 주는 설치 가능한 워크플로 중심 가이드가 필요할 때 더 유용합니다.

초보자도 사용할 수 있나요?

네, 빌드와 테스트 구성을 설명할 수 있다면 가능합니다. 필요한 핵심은 깊은 sanitizer 전문 지식이 아니라, 언어·컴파일러·플랫폼·재현 경로를 말할 수 있을 만큼의 프로젝트 맥락입니다. 그래야 스킬이 적절한 ASan 워크플로를 추천할 수 있습니다.

address-sanitizer 스킬 개선 방법

빌드와 런타임 세부 정보를 제공하세요

가장 좋은 address-sanitizer 결과는 정확한 컴파일러, 플랫폼, 테스트 명령에서 나옵니다. Clang을 쓰는지 GCC를 쓰는지, 어떤 sanitizer 플래그가 이미 켜져 있는지, 실패가 퍼즈 타깃에서 나는지 테스트 바이너리에서 나는지 독립 재현 케이스에서 나는지까지 포함하세요.

의심하는 메모리 패턴을 분명히 하세요

ASan 출력은 증상을 구체적으로 설명할수록 훨씬 더 바로 쓸 수 있습니다. out-of-bounds read, heap-use-after-free, stack overflow, double free, leak처럼요. “그냥 크래시 난다”라고만 하면 스킬이 너무 많은 것을 추정해야 해서 잘못된 빌드나 트리아지 경로를 제안할 수 있습니다.

다음 디버깅 단계를 요청하세요

첫 답변을 받은 뒤에는 가능한 한 작은 후속 질문으로 이어 가세요. 예를 들어 “이 재현 케이스를 어떻게 더 줄이죠?”, “이 스택 트레이스를 어떻게 해석하죠?”, “symbolization과 더 나은 리포트를 위해 어떤 ASan 플래그를 추가해야 하죠?”처럼요. 이렇게 하면 address-sanitizer skill이 넓은 sanitizer 이론이 아니라 지금 당장 중요한 판단에 집중할 수 있습니다.

흔한 실패 모드를 주의하세요

가장 흔한 실수는 완전한 계측 없이 빌드하는 것, sanitized 객체와 unsanitized 객체를 섞는 것, 그리고 ASan을 디버깅 신호가 아니라 exploitability의 증거로 오해하는 것입니다. address-sanitizer for Security Audit가 필요하다면 위협 모델과 코드 위치를 함께 제공해, 실제 메모리 손상과 이론적 위험을 구분할 수 있게 하세요.