NA> Во-первых, зачем по-умолчанию включены отладки GTHROW_LOG и NA> GTHROW_DEBUG? Я иногда видел какие-то трейсы про память пишутся в NA> golded.log, но реально, хоть что-то когда-нибудь присылал сюда в эху, NA> или куда-то, какие-то отладочные трейсы памяти?
Подозреваю, это сделали, чтобы было проще собирать отчеты об ошибках. Коряво, конечно. Для релизной сборки это все должно быть отключено. Оно и на производительность влияет не самым благоприятным образом.
Я посмотрю, как это удобно сделать отключаемым для релизной сборки. Основная проблема, что там целая куча систем сборки, начиная от cmake, заканчивая пачкой makefiles для разных систем.
NA> Отладка GTHROW_DEBUG в голдеде сделана таким образом, что они NA> аллоцируют памяти больше на структурку Throw, и прячут её в начале. NA> Перед адресом и после обкладывают магическими цифирками BEFOREVAL и NA> AFTERVAL, чтобы потом на недоезды и заезды проверить. Также они NA> двухсвязный список хранят, чтобы потом потерянную память напечатать. А NA> потом пришёл Гугл и запили ASAN билды, и такое делать в ручную уже NA> стало не нужно, так что выключить по-умолчанию я бы рекомендовал.
Мало того, realloc совсем не обязательно должен выделять память в новом месте. В случае с уменьшением куска, это вполне может быть тот же кусок. Другое дело, что в таком виде это вряд ли используется.
NA> Решилось мне прогнать UBSAN билд, и прямо на запуске, где происходит NA> сканирование всех областей (баз эх), случается UB
[...skipped...]
NA> Вобщем-то бага то и нет, но всё равно, я бы почиНИЛ NA> throw_realloc_debug(), пододвинул throw_ptrtodl() туда, где он реально NA> используется. Т.е. вот такой фикс бы влил, но.. у меня нет на гитхабе NA> аккаунта.
Создал Pull Request с твоей правкой. Ожидайте на линии, Ваш звонок очень важен для нас. :))
Best regards, Vitaliy Aksyonov.
... Были бы мозги, было б сотрясение. --- GoldED+/LNX 1.1.5-b20231007 * Origin: Aurora, Colorado (1:104/117)
