2

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 ?

Naderi
  • 154
  • 2
  • 14

4 Answers4

3

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!

tenfour
  • 36,141
  • 15
  • 83
  • 142
1

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.

user229044
  • 232,980
  • 40
  • 330
  • 338
  • May want to add that in your logging you can also use the __FILE__ and __LINE__ predefined macros to achieve what the OP is probably looking for. – Matt Jordan Jul 06 '11 at 13:47
  • I wouldn't say lack of debugging info is the "whole point" of release mode. I'd say different compiler optimization level (which can make debugging more difficult) is the main reason for different build configs. Also PDB can be created for release, as mentioned in other answers. – Aidan Ryan Jul 06 '11 at 14:40
  • @Aidan Yes, I agree. I meant stripping debugging info specifically as a subset of the the optimizations performed in release mode. – user229044 Jul 06 '11 at 15:08
1

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.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
0

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...?

Community
  • 1
  • 1
spraff
  • 32,570
  • 22
  • 121
  • 229