해설 — 강화 결과 완료 콜백과 취소의 경합 (use-after-free)

난이도: 최상

요약

EnhancementService::Start(B)가 만든 워커 스레드는 계산이 끝나면 request->context->ApplyResult(result)를 호출한다. 이때 request->context(A)는 단순한 raw 포인터 필드이고, Cancel이 다른 스레드에서 delete request->context; request->context = nullptr;을 실행하는 시점과 아무런 동기화 없이 경합한다. 워커 스레드가 request->context를 읽어 ApplyResult를 호출하려는 바로 그 순간에 Cancel이 같은 포인터를 delete해버리면, 워커 스레드는 이미 해제된 메모리에 대해 가상함수 호출(ApplyResult는 비가상이지만 멤버 접근 자체가 해제된 메모리를 대상으로 함)을 수행하게 되어 정의되지 않은 동작(use-after-free)이 발생한다. 운이 나쁘면 그 메모리가 이미 다른 목적으로 재할당되어 있어 엉뚱한 데이터가 캐릭터 상태인 것처럼 덮어써지거나, 크래시가 발생한다. 반대로 타이밍이 살짝 달라 ApplyResult 호출이 delete보다 먼저 완료되면, 취소되었어야 할 요청의 결과가 조용히 반영되어버려 정합성이 깨진다.

문제점

• 분류: 소유권이 불분명한 raw 포인터에 대한 동기화 없는 동시 접근 (해제와 접근의 경합)
• 증상: 플레이어가 강화 요청 직후 접속을 끊어 요청이 취소되는 타이밍이 계산 완료와 겹치면, (1) 드물게(타이밍에 따라) 크래시나 손상된 메모리 접근으로 인한 알 수 없는 오류가 발생하고, (2) 크래시가 나지 않는 타이밍에서는 취소되었어야 할 강화 결과가 캐릭터 상태에 반영되어버린다. AddressSanitizer 로 재현하면 명확한 heap-use-after-free 리포트를 얻을 수 있다.
• 재현 조건: Start로 요청을 만든 직후(계산이 끝나기 전, 약 50ms 내) 다른 스레드에서 Cancel을 호출해 delete request->context가 실행되는 타이밍과, 워커 스레드가 request->context->ApplyResult(...)를 호출하는 타이밍이 겹치도록 반복 실행하면(스트레스 테스트) 재현할 수 있다.
• 근본 원인:
  • (A) EnhancementRequest::context가 소유권이 불명확한 raw 포인터로 선언되어 있다. 누가 이 포인터의 수명을 최종적으로 책임지는지(워커 스레드인지, Cancel을 호출하는 스레드인지)가 코드상 정의되어 있지 않다.
  • (B) 워커 스레드가 request->context를 접근하기 직전에 "아직 유효한 포인터인가"를 검사할 방법이 없고, 검사와 실제 사용(ApplyResult 호출) 사이에 원자성도 없다. Cancel의 delete와 워커의 역참조가 어떤 락이나 동기화 장치로도 상호 배제되지 않는다.

수정안

컨텍스트의 수명을 std::shared_ptr로 관리해 "마지막까지 들고 있는 쪽이 해제"하게 만들고, 취소/완료 확정을 std::mutex + 상태 플래그로 상호 배제한다. Cancel은 더 이상 직접 delete하지 않고, "이 요청은 취소로 확정되었다"는 상태만 원자적으로 세팅한 뒤 컨텍스트에 대한 자신의 참조를 놓는다(마지막 참조가 사라질 때 shared_ptr가 자동으로 해제).

#include <chrono>
#include <memory>
#include <mutex>
#include <thread>

class EnhancementContext
{
public:
    int characterId = 0;
    int resultItemId = 0;
    bool applied = false;

    void ApplyResult(int item)
    {
        resultItemId = item;
        applied = true;
    }
};

enum class RequestState
{
    Pending,
    Completed,
    Cancelled,
};

class EnhancementRequest
{
public:
    explicit EnhancementRequest(std::shared_ptr<EnhancementContext> context)
        : context_(std::move(context))
    {
    }

    // 계산 완료 시 호출된다. 이미 취소되었다면 아무 것도 하지 않는다.
    void TryComplete(int resultItemId)
    {
        std::shared_ptr<EnhancementContext> contextToApply;
        {
            std::lock_guard<std::mutex> lock(mutex_);
            if (state_ != RequestState::Pending)
                return; // 이미 취소됨 — 결과를 버린다.

            state_ = RequestState::Completed;
            contextToApply = context_; // shared_ptr 복사 — 락 밖에서도 안전하게 살아있다.
        }

        contextToApply->ApplyResult(resultItemId);
    }

    // 취소 요청. 이미 완료되었다면 컨텍스트를 건드리지 않는다.
    void TryCancel()
    {
        std::lock_guard<std::mutex> lock(mutex_);
        if (state_ != RequestState::Pending)
            return; // 이미 완료됨 — 결과가 이미 반영되었으니 되돌리지 않는다.

        state_ = RequestState::Cancelled;
        context_.reset(); // 우리쪽 참조만 놓는다. 워커가 이미 복사해간 shared_ptr이
                           // 있다면(TryComplete 진행 중) 그쪽이 마지막 참조가 되어
                           // 안전하게 살아있다가 그쪽 소멸 시 해제된다.
    }

    std::thread worker;

private:
    std::mutex mutex_;
    std::shared_ptr<EnhancementContext> context_;
    RequestState state_ = RequestState::Pending;
};

class EnhancementService
{
public:
    std::shared_ptr<EnhancementRequest> Start(std::shared_ptr<EnhancementContext> context)
    {
        int characterId = context->characterId;
        auto request = std::make_shared<EnhancementRequest>(std::move(context));

        request->worker = std::thread([request, characterId]()
        {
            int result = ComputeEnhancementResult(characterId);
            request->TryComplete(result);
        });

        return request;
    }

    void Cancel(const std::shared_ptr<EnhancementRequest>& request)
    {
        request->TryCancel();
    }

private:
    static int ComputeEnhancementResult(int characterId)
    {
        std::this_thread::sleep_for(std::chrono::milliseconds(50));
        return (characterId * 7) % 100;
    }
};

핵심 변경은 두 가지다. 첫째, 컨텍스트 수명을 shared_ptr로 옮겨 "누가 마지막으로 들고 있느냐"가 곧 "누가 해제하느냐"가 되게 함으로써 raw delete가 만드는 UAF 창을 원천적으로 없앴다. 둘째, state_를 mutex로 보호된 단일 상태로 만들어 완료와 취소가 서로 배타적으로 확정되게 했다 — TryComplete와 TryCancel 둘 다 락 안에서 상태를 먼저 확정하고, 실제 컨텍스트 접근(ApplyResult/reset)은 그 확정 이후에 이뤄지므로 "확정된 상태와 실제로 일어나는 부수효과"가 항상 일치한다.

더 나은 설계

• shared_ptr + mutex 상태 머신(채택안): 소유권 문제와 경합 문제를 동시에 해결하며, 표준 라이브러리만으로 구현 가능해 이식성이 좋다. 다만 원자적 참조 카운트 증감 비용(shared_ptr 복사)이 있고, 워커 스레드를 join/detach하는 생명주기 관리는 별도로 신경써야 한다(위 스니펫은 지면상 생략했지만 실제로는 EnhancementRequest 소멸 전 worker.join()이 필요하다).
• std::atomic<RequestState> + 이중 확인(double-checked) 없이 compare_exchange로 상태만 전이: 락 없이 상태 전이는 원자적으로 하되, 컨텍스트 접근 자체는 여전히 shared_ptr에 위임. 락 경합을 줄일 수 있지만 메모리 순서(memory order)를 정확히 지정해야 하는 복잡도가 늘어난다.
• 작업 큐 + 단일 처리 스레드로 직렬화: 완료/취소 이벤트를 모두 하나의 처리 스레드가 순차적으로 소비하는 큐에 넣어, 애초에 동시 접근 자체가 발생하지 않게 만드는 설계. 동기화 프리미티브가 거의 필요 없어지는 대신, 그 처리 스레드가 병목이 될 수 있다.
• 트레이드오프: 강화처럼 요청당 지연이 이미 존재하고 동시 요청 수가 극단적으로 많지 않은 도메인에서는 shared_ptr + mutex 조합이 안전성과 구현 단순성 면에서 가장 균형 잡힌 선택이다. 초저지연·초고빈도 경로라면 락-프리 상태 전이나 직렬화 큐를 고려할 만하다.

면접 포인트

• raw 포인터로 표현된 "누가 이 객체를 해제할 책임이 있는가"라는 질문에 답이 없는 코드는 그 자체로 위험 신호라는 점 — 소유권을 shared_ptr/unique_ptr로 명시하는 것이 왜 동시성 버그를 원천적으로 줄이는지 설명할 수 있어야 한다.
• "완료 확정"과 "취소 확정"을 하나의 상호 배타적 상태 전이로 모델링해야 하는 이유, 그리고 상태 전이와 실제 부수효과(메모리 해제, 결과 반영)의 순서를 어떻게 락으로 묶어야 하는지 설명할 수 있어야 한다.
• AddressSanitizer/ThreadSanitizer 같은 도구가 이런 종류의 경합을 어떻게 잡아내는지, 그리고 실서비스에서 이런 버그가 "가끔씩만" 재현되는 이유(타이밍 의존성)를 설명할 수 있어야 한다.