해설 — 장비 젬 소켓 장착/제거의 동시 처리 (소유권 이중화·UAF, C++)

난이도: 중상

요약

SocketService 는 젬의 소유권(소멸 책임)을 인벤토리 벡터와 소켓 포인터 사이에서 옮기는데, "검사 → 이동" 전체가 원자적이지 않다. 동시 요청 시 같은 Gem* 가 두 곳에서 소유되거나(이중 free 위험), 어디에서도 소유되지 않아(누수) 소유권 불변식이 깨진다. C++에서는 여기에 더해 이미 반납·해제된 젬을 가리키는 dangling 포인터가 남을 수 있다.

문제점

분류 태그: check-then-act 경쟁 / 소유권 이중화·use-after-free

증상: 젬 개수가 늘거나(같은 포인터가 인벤토리에 2회) 줄고, 스트레스 테스트에서 이중 해제로 인한 힙 손상/크래시가 산발적으로 발생. ASan 은 "double-free" 또는 "heap-use-after-free" 를 소켓 접근 지점에서 보고.

재현 조건: 두 워커 스레드가 같은 equipId/slot 에 대해 unsocketGem/unsocketGem 또는 socketGem/unsocketGem 을 동시에 실행.

근본 원인:

1. 이중 제거 → 소유권 이중화: T1·T2 가 unsocketGem. 둘 다 (A)에서 같은 비-null g 를 읽는다. 둘 다 inv_->add(g) → 같은 Gem* 가 인벤토리 벡터에 두 번 들어간다. 이후 이 젬을 소비/삭제하는 경로에서 double free 또는 dangling 참조.
2. 장착/제거 교차 → 유실/덮어쓰기: T1 socketGem 이 (A)에서 빈 슬롯을 확인하고 take 로 젬을 얻은 뒤 (B) 직전에 멈춘다. 그 사이 T2 가 같은 슬롯을 다른 젬으로 채우면(다른 요청), T1 (B)가 그 포인터를 덮어써 T2 가 넣은 젬이 슬롯에서 사라진다(그 젬은 인벤토리에도 없으므로 누수 또는, 소멸자를 가진 소유 컨테이너였다면 UAF).
3. Inventory::gems_ 벡터의 동시 push_back/erase 는 재할당·반복자 무효화로 그 자체가 UB.

C++ 특유의 심각성: C#은 GC가 있어 "복제"는 논리 버그에 그치지만, C++는 같은 객체를 두 소유자가 delete 하려 하면 즉시 힙 손상으로 이어진다.

수정안

장비/인벤토리 상태 전체를 하나의 뮤텍스로 보호하고, 검사·소유권 이동·슬롯 갱신을 한 임계 구역에서 수행한다. 소유권은 std::unique_ptr 로 표현해 "정확히 한 곳"을 타입으로 강제한다.

#include <memory>
#include <mutex>
#include <vector>
#include <unordered_map>

struct Equipment {
    int equipId;
    std::vector<std::unique_ptr<Gem>> sockets;   // 소유권이 여기 또는 인벤토리
    explicit Equipment(int slots) : equipId(0), sockets(slots) {}
};

class Inventory {
public:
    void add(std::unique_ptr<Gem> g) { gems_.push_back(std::move(g)); }
    std::unique_ptr<Gem> take(int type) {
        for (std::size_t i = 0; i < gems_.size(); ++i)
            if (gems_[i]->gemType == type) {
                auto g = std::move(gems_[i]);
                gems_.erase(gems_.begin() + i);
                return g;
            }
        return nullptr;
    }
private:
    std::vector<std::unique_ptr<Gem>> gems_;
};

class SocketService {
public:
    explicit SocketService(Inventory* inv) : inv_(inv) {}
    void registerEquip(Equipment* e) { std::lock_guard<std::mutex> lk(m_); equips_[e->equipId] = e; }

    bool socketGem(int equipId, int slot, int gemType) {
        std::lock_guard<std::mutex> lk(m_);
        auto it = equips_.find(equipId);
        if (it == equips_.end()) return false;
        Equipment* e = it->second;
        if (slot < 0 || slot >= (int)e->sockets.size()) return false;
        if (e->sockets[slot]) return false;              // 검사
        auto g = inv_->take(gemType);
        if (!g) return false;
        e->sockets[slot] = std::move(g);                 // 소유권 이동 (한 곳)
        return true;
    }

    bool unsocketGem(int equipId, int slot) {
        std::lock_guard<std::mutex> lk(m_);
        auto it = equips_.find(equipId);
        if (it == equips_.end()) return false;
        Equipment* e = it->second;
        if (slot < 0 || slot >= (int)e->sockets.size()) return false;
        if (!e->sockets[slot]) return false;
        inv_->add(std::move(e->sockets[slot]));          // move 로 슬롯은 즉시 null
        return true;
    }
private:
    std::mutex m_;
    std::unordered_map<int, Equipment*> equips_;
    Inventory* inv_;
};

std::move 로 슬롯에서 인벤토리로 옮기면 슬롯은 그 순간 nullptr 이 되어 "이중 add" 자체가 불가능하다. unique_ptr 는 두 소유자를 컴파일/런타임 어느 쪽으로도 허용하지 않아 이중화·UAF 불변식을 타입으로 못박는다.

더 나은 설계

• 소유권을 타입으로 강제: raw Gem* 를 소유 목적으로 쓰지 말고 unique_ptr(단일 소유) 또는 명확한 아레나/풀 핸들(세대 검증 포함)로. "누가 지우는가"가 코드에 드러난다.
• 플레이어 단위 직렬화: 한 플레이어의 인벤토리/장비 변경을 단일 스레드/액터가 처리하면 뮤텍스조차 불필요하고 이 부류가 사라진다.
• 아레나 + 세대 핸들: 젬을 슬롯맵에 저장하고 (index, generation) 핸들로 참조하면, 재사용된 슬롯을 옛 핸들이 가리켜도 세대 불일치로 걸러져 ABA/UAF를 방지.
• 트레이드오프: 굵은 뮤텍스는 안전하지만 경합 시 처리량 저하. 액터/샤딩은 확장성이 좋으나 교차 트랜잭션(거래) 구현 복잡도 증가. unique_ptr 는 안전하지만 소유권 경계 설계를 강제.

면접 포인트

• C#의 "복제"와 C++의 "이중 free"가 같은 경쟁에서 왜 심각도가 다른가.
• std::move 로 슬롯을 비우는 것이 왜 이중 반납을 구조적으로 막는가.
• raw pointer 소유의 위험을 unique_ptr/세대 핸들로 어떻게 타입 수준에서 제거하는가.