Стек Valgrind пропускает функцию полностью

Ответ 1

Хорошо, компилирование всех .so частей, и основная программа с явным -O0, похоже, решает проблему. Похоже, что некоторые из оптимизаций "основной" программы, которая загружала .so(так всегда компилировалась неоптимизированным), ломала стек.

Ответ 2

Я вижу две возможные причины:

• Valgrind использует другой метод раскрутки стека, чем GDB
• Макет адресного пространства отличается при запуске вашей программы в двух средах, и вы только наносите вред стеку при использовании Valgrind.

Мы можем получить больше информации, используя встроенный gdbserver Valgrind.

Сохраните этот фрагмент Python до thread-frames.py

import gdb

f = gdb.newest_frame()
while f is not None:
    f.select()
    gdb.execute('info frame')
    f = f.older()

t.gdb

set confirm off
file MY-PROGRAM
break function
commands
silent
end
run
source thread-frames.py
quit

v.gdb

set confirm off
target remote | vgdb
file MY-PROGRAM
break function
commands
silent
end
continue
source thread-frames.py
quit

(Измените MY-PROGRAM, функция в приведенных выше сценариях и приведённые ниже команды)

Получить информацию о кадрах стека в GDB:

$ gdb -q -x t.gdb
Breakpoint 1 at 0x80484a2: file valgrind-unwind.c, line 6.
Stack level 0, frame at 0xbffff2f0:
 eip = 0x80484a2 in function (valgrind-unwind.c:6); saved eip 0x8048384
 called by frame at 0xbffff310
 source language c.
 Arglist at 0xbffff2e8, args: 
 Locals at 0xbffff2e8, Previous frame sp is 0xbffff2f0
 Saved registers:
  ebp at 0xbffff2e8, eip at 0xbffff2ec
Stack level 1, frame at 0xbffff310:
 eip = 0x8048384 in main (valgrind-unwind.c:17); saved eip 0xb7e33963
 caller of frame at 0xbffff2f0
 source language c.
 Arglist at 0xbffff2f8, args: 
 Locals at 0xbffff2f8, Previous frame sp is 0xbffff310
 Saved registers:
  ebp at 0xbffff2f8, eip at 0xbffff30c

Получить те же данные в Valgrind:

$ valgrind --vgdb=full --vgdb-error=0 ./MY-PROGRAM

В другой оболочке:

$ gdb -q -x v.gdb
relaying data between gdb and process 574
0x04001020 in ?? ()
Breakpoint 1 at 0x80484a2: file valgrind-unwind.c, line 6.
Stack level 0, frame at 0xbe88e2c0:
 eip = 0x80484a2 in function (valgrind-unwind.c:6); saved eip 0x8048384
 called by frame at 0xbe88e2e0
 source language c.
 Arglist at 0xbe88e2b8, args: 
 Locals at 0xbe88e2b8, Previous frame sp is 0xbe88e2c0
 Saved registers:
  ebp at 0xbe88e2b8, eip at 0xbe88e2bc
Stack level 1, frame at 0xbe88e2e0:
 eip = 0x8048384 in main (valgrind-unwind.c:17); saved eip 0x4051963
 caller of frame at 0xbe88e2c0
 source language c.
 Arglist at 0xbe88e2c8, args: 
 Locals at 0xbe88e2c8, Previous frame sp is 0xbe88e2e0
 Saved registers:
  ebp at 0xbe88e2c8, eip at 0xbe88e2dc

Если GDB может успешно размотать стек при подключении к " valgrind --gdb", тогда это проблема с алгоритмом разблокировки стека Valgrind. Вы можете тщательно проверить " информационный фрейм" для встроенных и хвостовых фреймов вызовов или по какой-либо другой причине, которая может выбросить Valgrind. В противном случае это может привести к повреждению.

Ответ 3

Это Оптимизация Tail-call в действии.

Функция function вызывает malloc как последнее, что она делает. Компилятор видит это и убивает фрейм стека function, прежде чем он называет malloc. Преимущество заключается в том, что при возврате malloc он возвращается непосредственно к той функции, которая называется function. То есть он избегает malloc, возвращаясь к function только для того, чтобы нажать еще одну команду возврата.

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

Как вы уже выяснили, отключение оптимизации упрощает отладку. Если вы хотите отлаживать оптимизированный код (возможно, для тестирования производительности), то, как уже сказал @Zang MingJie, вы можете отключить эту оптимизацию с помощью -fno-optimize-sibling-calls.