170 похожих чатов

Добрый день! Может кто-то помочь расшифровать вывод от GC, получившийся

в результате падения? Программа паникует со словами fatal error: found pointer to free object. Я так понимаю, это значит, что я куда-то спрятал указатель на объект, который GC подобрал, хотя у меня в коде этот указатель ещё будет использоваться (первый вопрос: правильно ли я понял суть ошибки?).
Вместе с паникой мне выводится большая таблица с, насколько я понял, памятью, которой пользовалась моя программа, и её статусом (в контексте GC). Таблица имеет следующий вид
0x... alloc marked
0x... free unmarked
И т.п. Проблемный указатель в ней записан так:
0xFOO free marked zombie
FOO: BAR <my/project/package.SomeFunction.func1+0> BAZ
Здесь FOO, BAR и BAZ - какие-то шестнадцатеричные числа. FOO - это, насколько я понимаю, как раз таки указатель, который был подобран GC. Знает ли кто-то,
1) что значат числа BAR и BAZ (BAZ похоже тоже на адрес указателя, но на пару десятков килобайт дальше FOO, а BAR значительно меньше и поэтому не похоже на адрес);
2) что значит запись в <>? Это указание на место, в котором обнаружен указатель на освобождённую память? Что в таком случае значит func1+0 (func1 - это вроде бы первая анонимная функция в скоупе SomeFunction, а что такое +0)?

4 ответов

18 просмотров

Как спрятали?

Arseny-Khoroshilov Автор вопроса
Zver
Как спрятали?

Долго объяснять, специфика задачи заставляет обмазываться кучей небезопасных практик. Но до недавнего времени всё работало довольно стабильно. Если вкратце, из C приходит память на структуру, в которую кладётся указатель на гошный объект (я знаю, что cgo сильно против таких махинаций, но...). Варианта "переделать архитектуру чтобы не заниматься такой ересью" к сожалению в данный момент нет. Для начала хочется понять всю информацию, которая содержится в crash report, а потом думать, как грамотнее это пофиксить.

Arseny-Khoroshilov Автор вопроса
Arseny Khoroshilov
Долго объяснять, специфика задачи заставляет обмаз...

Интересно, что указатель, отмеченный как zombie в репорте - это не указатель на объект, который мы отправляем в C, а указатель на 80 байт дальше (размер отправляемого объекта - 16 байт).

Arseny-Khoroshilov Автор вопроса

Отбой, мне кажется, я разобрался. Запись в <> - это не указание на функцию, где мы находим проблемный объект, а указание на сам проблемный объект. Т.е. GC потёр анонимную функцию, которая на самом деле тоже лежит в сишной памяти. Накинул на неё runtime.KeepAlive, вроде бы работает стабильно.

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта