【问题标题】:Function calls seen before _start and main in backtrace回溯中在 _start 和 main 之前看到的函数调用
【发布时间】:2011-07-19 23:50:58
【问题描述】:

我从一位同事那里收到了我的程序(在 RHEL 5.3 上运行的 qt 应用程序)的回溯,当我分析它时,我发现了一些我无法解释的东西。如果查看此回溯,您会注意到 main 和 _start 的跟踪。但在此之前,我们会在我的程序中看到 _ZN19datalog_render_area9prepStripEh 和 _ZN12QMutexLockerD1Ev。我怎样才能看到我的一些函数在 _start 和 main 之前被调用。那不是不可能吗? (请原谅我的回溯布局)

功能地址|指令。地址 |功能符号 ----------|-------------|-------------- ----------------------------------| 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 |主要的 _____________________|____________________|计划外地址:4804252 0x8060a70 | 0x8060a91 | _开始 _____________________|____________________|计划外地址:3218418744 0x808df02 | 0x808df13 | _ZN12QMutexLockerD1Ev _____________________|____________________|计划外地址:3218420336 _____________________|____________________|计划外地址:152429104 _____________________|____________________|计划外地址:3218420552 0x8208fa6 | 0x820acd0 | _ZN19datalog_render_area9prepStripEh _____________________|____________________|计划外地址:3218420336 _____________________|____________________|计划外地址:3218420500

【问题讨论】:

    标签: c++ linux qt gcc backtrace


    【解决方案1】:

    最有可能的是,您在堆栈上看到了垃圾。为了获得准确的堆栈跟踪,调试器需要帧指针(在 x86 上通常省略以保存寄存器)或调试信息。如果没有这些信息,它会尝试猜测 - 它会在堆栈中扫描看起来有点像代码地址的指针,并尽最大努力将它们与它们所属的函数相匹配。

    正如其他人所提到的,静态初始化会导致代码在main 之前执行,但是这段代码在main 运行时已经返回,所以他们在真正的堆栈跟踪上没有任何业务。我想说的是,很可能,_start 之外的所有内容都是垃圾数据,可以安全地忽略。

    【讨论】:

    • 这是个好主意。我正在调用深度为 300 的回溯函数,所以我可能就像你说的那样,看着垃圾。现在我想起来了,当我在那里重新创建 qt creator 调试器窗口时,我确定堆栈非常短。
    【解决方案2】:

    这是可能的。例如,这些函数可以作为某些静态存储持续时间对象的动态初始化的一部分调用。

    玩具示例:

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

    【讨论】:

    • 静态初始化器确实可能存在,但由于它们在 main 之前返回,它不应该出现在 main 的准确堆栈跟踪中。
    【解决方案3】:

    看起来您有一个具有静态数据成员的类。该静态数据成员的构造函数正在调用 QMutexLocker。静态数据成员在 main() 被调用之前构造。

    【讨论】:

    • 我会修改 _ZN19datalog_render_area9prepStripEh 直到它不再是静态的。可以从另一个线程的另一个对象访问数据成员,并且该特定变量可以很好地由该另一个线程同时写入/读取。这应该会导致一些事情
    • 我还检查了整个代码,发现我摆脱了 2 个静态成员。谢谢
    • @yan,另外,静态成员与静态构造函数不同。静态构造函数是指你有一个静态 data 成员,或一个静态 全局(或文件范围)变量,它的类型带有构造函数。
    • @yan,使用 c++filt 实用程序
    • 或者只是手动进行拆解:codesourcery.com/public/cxx-abi/abi.html#demangler_ZN=这是一个嵌套的错位名称。 12QMutexLocker:班级。 D1:完整的对象析构函数。 E:函数名结束。 v:无效参数。换句话说,_ZN12QMutexLockerD1Ev 表示~QMutexLocker()。同样,_ZN19datalog_render_area9prepStripEhdatalog_render_area::prepStrip(unsigned char)
    猜你喜欢
    • 2017-08-26
    • 2011-07-10
    • 2011-06-20
    • 1970-01-01
    • 2011-02-15
    • 2012-06-09
    • 1970-01-01
    • 2010-09-16
    • 1970-01-01
    相关资源
    最近更新 更多