Сработает ли деструктор, присвоив atomic?

Question

[Mercury13]

template <unsigned long long Rnd>
class DangleCanary {
public:
    DangleCanary() noexcept { value = rightCanary(); }
    ~DangleCanary() noexcept { value = 0; }

    DangleCanary(const DangleCanary&) noexcept {}
    DangleCanary& operator=(const DangleCanary&) noexcept { return *this; }
    void checkCanary() const;
private:
    std::atomic<uintptr_t> value = 0;
    uintptr_t rightCanary() const noexcept;
    static constexpr auto SCRAMBLE = static_cast<uintptr_t>(Rnd);
};

template <unsigned long long Rnd>
uintptr_t DangleCanary<Rnd>::rightCanary() const noexcept
    { return reinterpret_cast<uintptr_t>(this) ^ SCRAMBLE; }


template <unsigned long long Rnd>
void DangleCanary<Rnd>::checkCanary() const
{
    if (value != rightCanary())
        throw std::logic_error("[DangleCanary] Dangling link detected!");
}

Как вы понимаете, это простенький код для проверки, что данный объект существует и указатель на него не «повис в воздухе». Подобные штуки используются, когда имеем дело с тупыми указателями, проходящими через плохо контролируемую среду (QAbstractItemModel — ну или просто код, написанный неопытным прогером).

Меня конкретно интересует деструктор: может ли он «заоптимизировать» присваивание value = 0, убив весь смысл детектора висячего указателя?

Comments

[jcmvbkbc]

Я вижу, что value после выхода из деструктора будет недоступен извне, поэтому непонятно, какая разница, будет value = 0 оптимизировано или нет.

[Mercury13]

jcmvbkbc, Читай описание: это проверка на повисший указатель! Если указатель смотрит на уничтоженный объект, проверка должна провалиться раньше, чем будет сделано что-то деструктивное.
Задача: память портится, кто портит — непонятно.

[Армянское Радио]

Mercury13, Valgrind и его друзья ничего интерсного не пишут?

[Mercury13]

Армянское Радио, А под Windows ValGrind вообще бывает?

[Армянское Радио]

Mercury13, Аналоги бывают

[jcmvbkbc]

Читай описание

Mercury13, я тебе предлагаю всякий раз, когда ты хочешь написать "читай описание" отвечать самому себе: "так ни*ра непонятно из твоего описания" "по-видимому в описании не хватает существенных деталей, либо они недостаточно чётко выражены" , это сэкономит немного времени нам всем. В описании данного вопроса недостаёт обоснования, почему atomic по-твоему подходит в качестве решения и описания или примера кода который используется для проверки value.

По сути: средствами языка ты извне к полю value доступа не имеешь, поэтому глупо рассчитывать на компилятор. В данной ситуации я бы сделал value volatile (не atomic), поскольку обращение к volatile является обозреваемым поведением программы и компилятор обязан его сохранить.

Answer 1

[Wataru]

Не совсем понятно, а чего вы вообще пытаетесь добиться зануляя value? После деструктора весь объект и его член value уничтожаются. Любое обращение к ним - это UB. Соотвтественно вы этот новый 0 никак снаружи пощупать не сможете.

Теоретически компилятор мог бы понять, что эта инструкция не может иметь никаких эффектов и удалить ее нафиг. Но даже если он этого не сделает - как это должно проверять на висящие указатели, я не понимаю.

Единственный способ бороться с этим, кажется, это использовать умные указатели. Всякие WeakPtr, которые не уничтожают блок счетчиков при удалении объекта. Если же вы опустились до сырых указателей, то это тупо адрес (число). И просто по нему никак не понять, а что по этому адресу лежит - оригинальный объект или что-то левое.

Comments

[Mercury13]

Да, да, да! Я детектирую повисшие указатели. У живого объекта проверочная цифра правильная, а у умершего — сбита.
1. QModelIndex слишком мал, чтобы держать умный указатель.
2. Объект может быть потёрт не только деструктором, но и совершенно посторонним кодом.

[Wataru]

Mercury13,

У живого объекта проверочная цифра правильная, а у умершего

Умершего объекта обычно больше нет. Его память возвращена системе, или переиспользована для других данных компилятором. Любое обращение к памяти объекта после вызова деструктора (если вы его руками, конечно, не вызываете) - это уже обращение по висящему указателю, что есть UB.

Если же вы сами руками вызываете деструктор у объекта (при этом у вас должен быть собственный какой-то менеджер памяти), то в этом случае, раз вы все еще хотите обращатся к какому-то полю объекта, вам стоит его не уничтожать, а переводить в "невалидное" состояние. Память все-равно не освобождена - ведь иначе UB будет. Для этого будет достаточно тупо bool is_alive и не надо какую-то защиту с канарейками городить. Ну или использовать первые несколько байт для пометки о валидности объекта, а остальные реинтерпритировать как ваш объект, тогда проверка будет как бы отдельно от логики самого объекта.

QModelIndex слишком мал, чтобы держать умный указатель

Не совсем понимаю контекст.

Объект может быть потёрт не только деструктором, но и совершенно посторонним кодом.

Это каким таким кодом? Если только у вас не собственный менеджер памяти, то объект трется при вызове delete на указателе, или после выхода переменной из scope. А деструктор обычно не трет объект, а лишь вызывается автоматически перед его "удалением" (не считая вызова free какого-нибуть).

[Mercury13]

QModelIndex слишком мал, чтобы держать умный указатель

Не совсем понимаю контекст.

QModelIndex содержит четыре поля: модель, строка, столбец и 8-байтовый указатель на что угодно. А shared_ptr, во-первых, шестнадцать байт, во-вторых, управляемый и даже на x86 протаскивать через посторонний тип не стоит.

[Mercury13]

Wataru, Что под капотом у Qt, хрен поймёшь, и много раз было: на старом Qt работало, на новом нет.

[Wataru]

Mercury13, Короче. Я понял. Это у вас оппортунистская проверка - задетектить UB после того, как оно произойдет. Оппортунистское, потому что все-равно может на какой-нибудь системе упасть во время проверки данных не в своей памяти, плюс то что там кто-то левый положет потом может случайно стать равно SCRAMBLE.

И ответ на ваш вопрос - нет, компиялтор может и удалить. Есть всякие платформо-зависимые функции для гарантированного зануления памяти, но как их прикрутить к атомикам - я не знаю. Но вообще компилятор может додуматся, что во время жизни объекта value не меняется и вообще удалить проверку нафиг.

Я бы не городил этот огород, а использовал тот же valgrind для проверки. Ну или, если хотите, то вам придется написать собственный менеджер памяти. Переопределить new и delete и или не удалять память вообще и там внутри где-то как-то помечать (например, выделить на 4 байт больше перед данными). Или где-то запоминать, что память отчищена и проверять на висячие указатели какой-то функцией, отдельной от возможно удаленного объекта.

[Mercury13]

Wataru, Упала сразу же — это круто! Хуже, когда не упала и потихоньку портит память.

[Wataru]

Mercury13,

Упала сразу же — это круто! Хуже, когда не упала и потихоньку портит память.

Гарантий никаких нет. Поскольку ваша проверка сама содержит в себе UB, может быть что угодно.

[RabraBabr]

Mercury13, У умершего может быть вообще, что угодно без каких либо гарантий. Там классическое UB. Имхо это вообще не валидная стратегия. К тому же и компилятор не даст ни каких гарантий по поводу value. В общем пример того как делать ненадо.

[Wataru]

Mercury13, Добавлю, что вы пытаетесь детектировать UB через другое UB. То, что оно иногда сработает лишь даст вам ложную илюзию отстуствия UB в вашем коде. Если всякие аналоги valgrind не вариант, то подумайте над тем, как передавать через qt не голые указатели. Хоть guid, хоть индекс в массиве объектов будет тогда уж лучше, если наличие вот этого не-вашего кода так все усложняет, что надо городить всякие хаки для проверки на висячие указатели.

[Евгений Шатунов]

Mercury13, я правильно понимаю что проверку на повисший указатель ты выполняешь через вызов checkCanary() для этого указателя?

[Mercury13]

Евгений Шатунов, Каждый раз, когда он проходит через что-то чувствительное — например, тот же QModelIndex.

[Евгений Шатунов]

Mercury13, ну вот в тот момент, когда ты вызовешь метод у повисшего указателя, у тебя будет UB.
Т.е. твой код сейчас опаснее чем был до всех твоих изменений. Раньше он только потенциально содержал UB, сейчас - принципиально содержит.
Убирай этот код если хочешь повысить надежность. Повисший указатель ты никак не отследишь без системных средств. Меняй указатель на косвенную адресацию. Храни не указатель, а индекс и по индексу определяй живучесть объекта.

[Mercury13]

Евгений Шатунов, А если система древовидная и надо в таком случае хранить не один индекс, а несколько от корня?

[Евгений Шатунов]

Mercury13, а неправильно рассуждаешь.
У тебя есть 8 байт. Запиши туда хендл на размещение объекта. Хендл должен представлять из себя индекс размещения. Тип хендла должен предоставлять operator -> () для предоставления доступа к объекту по своему индексу. С проверкой, конечно. Все, пляши от этих условий.
Если у тебя теряются узлы живого дерева - это проблема уже твоего кода, дерево же твоим кодом сделано.

Дальше тебе уже виднее, где и как держать таблицу для хендлов, что туда писать и как очищать там ячейку в момент деструкции объекта.
У меня в геймдеве для DOD хендлы представляются парой порядкового индекса ячейки и количества раз записи в эту ячейку. Таким образом, если хендл висит, ячейку освободили и заняли снова, когда по висящему хендлу попробуют обратиться к объекту, это приведет к ошибке потому что в ячейку записали уже больше раз чем хранит хендл.

[Wataru]

Mercury13, Древовидная система может использовать не указатели (адреса), а индексы объектов в ввекторе. Сами ваши объекты создаются и удаляются в каком-то массиве. Свободное место можно в этом массиве организовать в список использую уже имеющееся поля у объектов. В такой структуре вы сможете за O(1) освободить элемент или создать новый. Пометить его пустым, или удаленным.