0

I am trying to get stack trace in release (optimized) build without pdb-s. Currently I am trying to retrieve function addresses during my sample program execution using StackWalk64 function and then map generated addresses to the actual function names using map file generated during linking stage. Please note that optimization is turned on.
I see absolutely identical addresses for two different functions in the generated map file. 

 0001:00000000       ?static_function_call@MyTest@@SAXXZ 00401000 f i main.obj
 0001:00000000       ?call_1@MyTest@@QAEXXZ     00401000 f i main.obj

What could be the reason of such a thing, can it be due to optimization ? Then how can this functions be distinguished ? EDIT: Here is the function bodies 

#include <iostream>
#include <windows.h>
#include <dbghelp.h>

class __declspec(dllexport) MyTest
{
 public:
   static void static_function_call()
 {
 }
 void call_1()
 {
    static_function_call();
 };
 };

 int main( void )
 {
    try
    {
       MyTest obj;
       obj.call_1();
    }
    catch( ... )
    {
    }
    return ( 0 );
}

Thank you, -Grigor

Grigor Aleksanyan
  • 367
  • 2
  • 14
  • Demangle the names and they are `public: void __thiscall MyTest::call_1(void)` and `private: static void __cdecl MyTest::static_function_call(void)`, can you show the source for these two `MyTest` methods – David Heffernan Feb 22 '16 at 13:41
  • Hi David, Please find the source code in my updated question. I have just added the required part to it. thank you - Grigor – Grigor Aleksanyan Feb 22 '16 at 14:15
  • I also updated map file section with a few lines. – Grigor Aleksanyan Feb 22 '16 at 14:21
  • The code that you show does not match the demangling. Can you provide a [mcve] because at the moment I don't believe that the content of the question is accurate. Which is intensely frustrating. – David Heffernan Feb 22 '16 at 14:23
  • The functions `call_2`, `call_3`, etc. are probably identical. – Raymond Chen Feb 22 '16 at 14:30
  • 1
    Possible duplicate of [Pointers of several functions](http://stackoverflow.com/questions/12167220/pointers-of-several-functions) – Raymond Chen Feb 22 '16 at 14:38
  • Hi, yes, they were absolutely identical, they just were calling each other. I used those functions to test my code. I was checking whether I am able to retrieve correct stack trace(function addresses) or not for specific functions call chain. I removed all unneeded stuff from the source and map file part. Please see the minimal code that produces the case. – Grigor Aleksanyan Feb 22 '16 at 14:50
  • I think that you have your explanation now, right? – David Heffernan Feb 22 '16 at 14:53
  • I would be grateful if you answer the question in some details. – Grigor Aleksanyan Feb 22 '16 at 14:57
  • After inlining, `static_function_call` and `call_1` are identical. – Raymond Chen Feb 22 '16 at 14:58
  • Hi Raymond. Just noticed the link you have provided, that makes perfect sense. Thank you. – Grigor Aleksanyan Feb 23 '16 at 12:49
  • Some questions remain: Why aren't you generating PDBs for your release configurations? Why do you need a stack trace? Wouldn't a minidump be more appropriate (minidumps can include a compact binary representation of a stack trace)? – IInspectable Feb 23 '16 at 14:42
  • We are distributing our application without .pdb files to conserve space on client machines and download bandwidth.I'm also not allowed to produce minidump as it requires further investigation in development. What we want is to make our processes write function names into the log before they exit(during the crash). We are fully Ok to get only function names(not lines). I am trying to get function offset in PE image and then map addresses to the actual functions using map files, but it doesn't seem to work very well when compiler optimization is on.I will really appreciate any help on this! – Grigor Aleksanyan Feb 23 '16 at 15:30
  • The issue is caused by ICF. Your choices are either to live with it, or to disable ICF. – Raymond Chen Feb 24 '16 at 08:42
  • Disabling only ICF doesn't resolve the issue. Only when I turn whole optimization off I start getting accurate stack. – Grigor Aleksanyan Feb 24 '16 at 11:18
  • Whole program optimization will do inlining, which is a different problem that will result in funny-looking stack traces. – Raymond Chen Feb 24 '16 at 14:51
  • Yes, inlining is another problem. I hope that large functions from our production source code will be accurately represented on the stack with this approach. I am going to try it out for our main dll. I believe that compiler can't optimize production code as good as it does the small examples I was looking on. Do I understand you correctly that you think there is no way to get normal stack without pdbs for release builds ? – Grigor Aleksanyan Feb 24 '16 at 22:57
  • Again, why are you trying to reinvent the wheel, poorly? Write a minidump (with just a stack trace) at the point where the crash happens. You don't need to redistribute PDB files. Those are only required when you open the minidump in a debugger, and want to have symbolic information. – IInspectable Feb 25 '16 at 14:14
  • I can't describe here every detail why we don't want minidumps. You should understand that I absolutely agree with your point of view.But our goal is to provide a mechanism to be able to quickly determine who is responsible for specific crash,so that issue could be quickly redirected to correct developer,without more investigation. This can be achieved if we see function names where crash occurred.You can look into this not as a task that will help us to understand where exactly issue was risen but as a task that would allow us quickly determine correct person that should look into the issue. – Grigor Aleksanyan Feb 25 '16 at 15:26

0 Answers0