> Что-то я туплю, но где именно оно там падает? Вруг можно без
> хака с флагом пофиксить?

оно падает где‐то во глубине сибирских руд^w^w delete, куда оно зачем‐то попадает с `data.attrs == NULL`, а попадать туда оно не должно, потому что delete должно быть толерантно к нулам.

причём падаем именно в этом одном конкретном месте, больше я нигде подобных падений не выловил. так что это не баг в оперном delete (я даже не уверен, что они его перекрывают — по‐моему, нет), это баг в оптимизаторе. дополнительно можно убедиться, что именно оптимизатор, если вспомнить, что -O0 не падает.

соответственно, компилятор у нас дохрена умный, и
if (data.attr) delete data.attr[];
не работает, потому что компилятор знает, что delete безопасно вызывать с нулами, и проверку нафиг аннигилирует.

поскольку про флаг я не знал, не знал, а потом вдруг забыл, то я просто вставил вызов функции с сайд‐эффектом, и это помогло.

дизасм я не смотрел, но судя по всему где‐то облажался register allocator.

p.s.: -O2 лажает точно так же, как и -O3. я всё равно на всякий случай понизил до -O2 — целее будем.

p.p.s.: я сильно подозреваю, что это очередной случай, когда компилятор тупо считает: «программ с UB нет и быть не может». там выше цикл, который снимает у attr атрибут внутренней очистки, и в принципе, он без охраны. поэтому компилятор вправе считать, что после цикла data.attr никогда не NULL, даже если цикл в принципе выполнился ноль раз (а после вызова функции, в которую компилятор не может заглянуть, он вынужден заново проверять). вполне возможно, что поэтому и беда. ибо новые компиляторы всё больше оптимизаций делают основываясь на идиотской идее про UB.

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