==14392==ERROR: AddressSanitizer: stack-use-after-...

Нет, проблема, скорее всего, не в std::wstring ws(buf); самой по себе.

По вашему ASan-логу важнее вот это:

• stack-use-after-scope
• адрес помечен как f8 = Stack use after scope
• падение происходит внутри конструктора std::wstring, но это часто означает, что к моменту создания ws уже испорчен стек или используется ссылка/указатель на локальный объект, который уже умер.

То есть строка

cpp
std::wstring ws(buf);

обычно здесь жертва, а не источник.

Почему именно так

Если бы проблема была в buf, вы бы чаще увидели что-то вроде:

• stack-buffer-overflow
• invalid read
• heap-buffer-overflow

А тут ASan говорит, что идет запись в область стека, которая уже считается вышедшей из scope. Это очень похоже на один из сценариев:

1. Где-то раньше сохранили указатель/ссылку на локальную переменную
2. Повредили стек до этой строки
3. Есть ложное срабатывание/артефакт ASan + оптимизации + MSVC, но это реже, чем реальная порча стека

---

Что в вашем коде стоит проверить сразу

1. GetModuleFileNameW и нуль-терминатор

Вот это место небезопасно:

cpp
wchar_t buf[MAX_PATH]{};
GetModuleFileNameW(nullptr, buf, MAX_PATH);
std::wstring ws(buf);

GetModuleFileNameW не гарантирует нуль-терминатор, если путь был обрезан по MAX_PATH.

Надо делать так:

cpp
wchar_t buf[MAX_PATH]{};
DWORD len = GetModuleFileNameW(nullptr, buf, MAX_PATH);
if (len == 0 || len >= MAX_PATH) {
    return -1; // или ваш код ошибки
}
std::wstring ws(buf, len);

Это не очень похоже на ваш stack-use-after-scope, но это все равно баг, который надо исправить.

---

2. ws.resize(pos);

Если find_last_of не найдет \\ или /, то pos == std::wstring::npos, и resize(pos) — это уже UB/исключение.

Надо:

cpp
const auto pos = ws.find_last_of(L"\\/");
if (pos == std::wstring::npos) {
    return -2;
}
ws.resize(pos);

---

3. Глобальные/статические ссылки на временные или локальные объекты

Вот это безопасно:

cpp
const std::string& exeDir = g_exeDirCache;

потому что g_exeDirCache — не локальная переменная.

Но очень похоже, что вокруг AgpInit или до него есть код, где:

• сохраняется wchar_t* на локальный буфер
• сохраняется std::wstring_view / std::string_view на временную строку
• сохраняется ссылка на локальный std::string / std::wstring
• где-то есть callback/lambda, захватившая локальную переменную по ссылке

И потом это бьет стек, а проявляется уже на std::wstring ws(buf).

---

Самый вероятный вывод по вашему логу

С высокой вероятностью:

ошибка находится не на строке 4730, а раньше — в коде, который повредил стек или оставил висячую ссылку на локальный объект.

---

Как сузить причину быстро

Перепишите этот кусок в безопасном виде

cpp
extern "C" __declspec(dllexport) int AgpInit() noexcept {
    g_env = new boost::mpi::environment();
    g_world = new boost::mpi::communicator();

    _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
    _MM_SET_DENORMALS_ZERO_MODE(_MM_DENORMALS_ZERO_ON);

    const int rank = g_world->rank();
    if (rank == 0) {
        wchar_t buf[MAX_PATH] = {};
        DWORD len = GetModuleFileNameW(nullptr, buf, MAX_PATH);
        if (len == 0 || len >= MAX_PATH) {
            return -1;
        }

        std::wstring ws(buf, len);

        const auto pos = ws.find_last_of(L"\\/");
        if (pos == std::wstring::npos) {
            return -2;
        }
        ws.resize(pos);

        const int n = WideCharToMultiByte(CP_UTF8, 0, ws.c_str(), -1, nullptr, 0, nullptr, nullptr);
        if (n <= 0) {
            return -3;
        }

        g_exeDirCache.resize(static_cast<size_t>(n - 1));
        WideCharToMultiByte(CP_UTF8, 0, ws.c_str(), -1, g_exeDirCache.data(), n, nullptr, nullptr);

        g_pyInterpreter = new pybind11::scoped_interpreter{};
        pybind11::module_ sys = pybind11::module_::import("sys");
        pybind11::list path = sys.attr("path");

        const std::string& exeDir = g_exeDirCache;
        path.attr("insert")(0, pybind11::str(exeDir + "\\env\\Lib\\site-packages"));
        path.attr("insert")(0, pybind11::str(exeDir + "\\env\\Scripts"));
        path.attr("insert")(0, pybind11::str(exeDir + "\\env"));
        path.attr("append")(pybind11::str(exeDir));

        pybind11::module_::import("warnings").attr("filterwarnings")("ignore");
        g_pyOptimizerBridge = new pybind11::module_(pybind11::module_::import("optimizer_bridge"));
    }
    return rank;
}

---

Еще один важный момент: noexcept

У вас функция объявлена как:

cpp
extern "C" __declspec(dllexport) int AgpInit() noexcept

Но внутри вызывается куча вещей, которые могут бросить исключение:

• new
• std::wstring
• std::string::resize
• pybind11::module_::import
• pybind11::scoped_interpreter

Если там вылетает исключение, при noexcept вы получите std::terminate, и отладка будет сильно путаться.

На время диагностики лучше убрать noexcept или хотя бы обернуть всё в try/catch.

Например:

cpp
extern "C" __declspec(dllexport) int AgpInit() {
    try {
        ...
    } catch (const std::exception& e) {
        return -100;
    } catch (...) {
        return -101;
    }
}

---

Что я бы проверил прямо сейчас

1. Все string_view / wstring_view
2. Все глобальные const char* / const wchar_t*
3. Все лямбды с захватом по ссылке
4. Все места, где возвращается c_str() от временной строки
5. Всё, что выполняется перед AgpInit и могло испортить стек

Особенно ищите такое:

cpp
const wchar_t* p = someLocalWstring.c_str();   // плохо, если someLocalWstring потом умирает
std::wstring_view v = local_wstring;           // плохо, если view живет дольше строки
global_ref = local_string;                     // плохо, если это ссылка

---

Итог

По вашему логу:

• ASan не указывает, что ошибка в buf
• строка std::wstring ws(buf); — скорее место проявления
• вероятная причина — висячая ссылка/указатель на локальный объект или повреждение стека раньше
• сам код при этом тоже стоит поправить:
  • использовать длину из GetModuleFileNameW
  • проверить npos
  • убрать noexcept на время диагностики

Если хотите, я могу дальше помочь точечно: разберу весь AgpInit построчно и покажу, какие места в нём реально опасны, а какие нет.