当项目在发布模式下崩溃时如何获取函数名称和行号

发布于 2024-11-18 12:09:48 字数 657 浏览 0 评论 0 原文

我有一个 C++/MFC 项目,

当我在调试模式下运行它时,项目崩溃了 我可以获得代码的函数和行号 使用 SetUnhandledExceptionFilter 函数 但在发布模式下我无法得到它,

我正在测试此函数和源

_set_invalid_parameter_handler msdn.microsoft.com/en-us/library/a9yf33zb(v=vs.80).aspx

StackWalker http://www.codeproject.com/KB/threads/StackWalker.aspx

MiniDumpReader & crashrpt http://code.google.com/p/crashrpt/

StackTracer www.codeproject。 com/KB/exception/StackTracer.aspx

当项目在发布模式下崩溃时获取函数和代码行的任何方法 不需要 pdb 文件或映射文件或源文件?

i have a project in C++/MFC

when i run its in debug mode and project crashed
i can get function and line number of code
with SetUnhandledExceptionFilter function
but in release mode i can not get it

i am test this function and source

_set_invalid_parameter_handler msdn.microsoft.com/en-us/library/a9yf33zb(v=vs.80).aspx

StackWalker http://www.codeproject.com/KB/threads/StackWalker.aspx

MiniDumpReader & crashrpt http://code.google.com/p/crashrpt/

StackTracer www.codeproject.com/KB/exception/StackTracer.aspx

any way to get function and line of code when project crashed in release mode
without require pdb file or map file or source file ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

情栀口红 2024-11-25 12:09:48

PDB 文件旨在为您提供此信息;缺陷是您不需要 PDB 文件。我可以理解不想将 PDB 发布给最终用户,但在这种情况下,为什么您希望他们看到堆栈跟踪信息?对我来说,你的目标是自相矛盾的。

从最终用户收集调试信息的最佳解决方案是通过小型转储,而不是通过在客户端上拼凑堆栈跟踪。

因此,您有几个选择:

  1. 使用小型转储(理想且相当常见)
  2. 发布 PDB(其中不会包含比您已经尝试推断的更多的信息)
  3. 在应用程序中使用内联跟踪信息,例如 __LINE____FILE____FUNCTION__
  4. 如果您无法拼凑出有意义的堆栈跟踪,只需捕获崩溃地址即可。

希望这有帮助!

PDB files are meant to provide you this information; the flaw is that don't you want a PDB file. I can understand not wanting to release the PDB to end users, but in that case why would you want them to see stack trace information? To me your goal is conflicting with itself.

The best solution for gathering debug info from end users is via a minidump, not by piecing together a stack trace on the client.

So, you have a few options:

  1. Work with minidumps (ideal, and quite common)
  2. Release the PDBs (which won't contain much more info than you're already trying to deduce)
  3. Use inline trace information in your app such as __LINE__, __FILE__, and __FUNCTION__.
  4. Just capture the crash address if you can't piece together a meaningful stack trace.

Hope this helps!

黒涩兲箜 2024-11-25 12:09:48

您可以从链接器获得详细输出,该输出将显示每个函数在可执行文件中的位置。然后,您可以使用崩溃报告中的偏移量来确定正在执行哪个函数。

You can get verbose output from the linker that will show you where each function is placed in the executable. Then you can use the offset from the crash report to figure out which function was executing.

ヤ经典坏疍 2024-11-25 12:09:48

在发布模式下,此类调试信息不​​包含在二进制文件中。您不能使用根本不存在的调试信息。

如果您需要调试发布模式代码,请通过写入日志文件或标准输出来开始手动跟踪执行情况。您可以使用 __FUNCTION____LINE__ 包含有关代码出现位置的信息,编译器会将其替换为它们出现的函数/行。还有许多其他有用的预定义宏您可以使用它来调试代码。

这是一个非常基本的 TR 宏,您可以将其散布在代码中以跟踪执行流程。

void trace_function(const char* function, int line) {
  std::cout << "In " << function << " on line " << line << std::endl;
}

#define TR trace_function(__FUNCTION__, __LINE__)

通过将 TR 放置在每个函数的顶部或您想要确保执行流程达到的任何位置来使用它:

void my_function() {
   TR();
   // your code here
}

不过,最好的解决方案是在调试模式下进行调试。

In release mode, this sort of debugging information isn't included in the binary. You can't use debugging information which simply isn't there.

If you need to debug release-mode code, start manually tracing execution by writing to a log file or stdout. You can include information about where your code appears using __FUNCTION__ and __LINE__, which the compiler will replace with the function/line they appear in/on. There are many other useful predefined macros which you can use to debug your code.

Here's a very basic TR macro, which you can sprinkle through out your code to follow the flow of execution.

void trace_function(const char* function, int line) {
  std::cout << "In " << function << " on line " << line << std::endl;
}

#define TR trace_function(__FUNCTION__, __LINE__)

Use it by placing TR at the top of each function or anywhere you want to be sure the flow of execution is reaching:

void my_function() {
   TR();
   // your code here
}

The best solution though, is to do your debugging in debug mode.

︶ ̄淡然 2024-11-25 12:09:48

您可以分隔调试符号,以便您的发布版本是干净的,然后将它们与核心转储放在一起以随后诊断问题。

这适用于 GNU/Linux,不确定 Microsoft 的等效项是什么。有人提到 PDB...?

You can separate the debug symbols so that your release version is clean, then bring them together with the core dump to diagnose the problem afterwards.

This works well for GNU/Linux, not sure what the Microsoft equivalent is. Someone mentioned PDB...?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文