Вызовы функций видны до _start и main в backtrace

Question

Я получил обратный след моей программы (приложение qt, работающее на RHEL 5.3) от коллеги, и, анализируя ее, я нашел то, что не смог объяснить. Если вы посмотрите на эту обратную трассировку, вы заметите трассировку для main и _start. Но перед этим мы видим _ZN19datalog_render_area9prepStripEh и _ZN12QMutexLockerD1Ev, которые есть в моей программе. Как я могу увидеть, как некоторые из моих функций вызывают до _start и main. Разве это невозможно? (простите за расположение моего следа)

Funct Addr| Instr. Addr | FunctionSymbol  
----------|-------------|----------------------------------------------------------|  
0x8060bf2 | 0x8060dc0   | _Z11print_tracev  
0x8061386 | 0x806141c   | _Z15myMessageOutput9QtMsgTypePKc  
0x822b558 | 0x822b598   | _ZN5QListIP13QStandardItemEixEi  
0x8229ece | 0x8229f0b   | _ZN12vehicleModel14updHeaderModelEP5QListIjE  
0x822be7e | 0x822bf64   | _ZN14vehTableWidget19updVehicleTabLayoutEib  
0x822c668 | 0x822c8e7   | _ZN14vehTableWidget13setupVehTableEib  
0x82845f8 | 0x82846fc   | _ZN14vehTableWidget11qt_metacallEN11QMetaObject4CallEiPPv

... вызовы функций вне программы

0x8060e86 | 0x80612ce | main  

_____________________|____________________|address outside of program: 4804252  

0x8060a70 | 0x8060a91 | _start  

_____________________|____________________|address outside of program: 3218418744  

0x808df02 | 0x808df13 | _ZN12QMutexLockerD1Ev    

_____________________|____________________|address outside of program: 3218420336  
_____________________|____________________|address outside of program: 152429104  
_____________________|____________________|address outside of program: 3218420552  

0x8208fa6 | 0x820acd0 | _ZN19datalog_render_area9prepStripEh  

_____________________|____________________|address outside of program: 3218420336  
_____________________|____________________|address outside of program: 3218420500  

Answer 1

Скорее всего, вы видите мусор в стеке. Чтобы получить точную трассировку стека, отладчику нужны либо указатели фреймов (которые часто не используются в x86 для сохранения регистра), либо отладочная информация. Без этой информации он пытается угадать - он просматривает в стеке указатели, которые выглядят как своего рода адреса кода, и старается сопоставить их с функциями, которым они принадлежат.

Как уже упоминалось, статическая инициализация может привести к выполнению кода до того, как main, но этот код вернулся к моменту запуска main, поэтому они не имеют никакого отношения к истинной трассировке стека. Я бы сказал, что, скорее всего, все, что находится за _start, является данными мусора и может быть безопасно проигнорировано.

Answer 2

Похоже, у вас есть класс со статическим членом данных.Конструктор для этого статического члена данных вызывает QMutexLocker.Элементы статических данных создаются до вызова main ().

Answer 3

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

Пример игрушки:

const bool i = []() -> bool
{
    // arbitrary code here
    return true;
}();

int
main()
{}