Does stack trace reflect dangerously in release builds?

Question

In C #, consider the following statement:

string operation = new StackTrace(false).GetFrame(0).GetMethod().Name; 

Is this a dangerous construct in a release build where frames can be compiled into native code?

Answer 1

No, this is not dangerous for everyone, but you may not get all the necessary information from the release build, which was built without debugging symbols. Here is some information from MSDN :

StackTrace information will be most informative with Debug build configurations. By default, the Debug assembly includes debugging symbols, but not in Release versions. Debug symbols contain most of the file name, method, line number, and column information used in constructing the StackFrame and StackTrace objects.

Answer 2

CLR gives very strong guarantees regarding stacks. Necessarily so, they are very important to make a garbage collector and secure access to the code. What you cannot count on, however, is that GetFrame (0) gives you the stack stack of your method. Invalid code is an important jitter optimization. At least not without explicit suppression of optimization using [MethodImpl], pointing MethodImplOptions.NoInlining to your method.

Both stacks and suppression of road optimization, so make sure this code is not in your critical path.

Compiler support for this function will be added to the next version of C # version 5 with the attribute [CallerMemberName] .

Answer 3

AFAIK no.

Everything compiles to IL anyway. The methods will be known, you just need the pdb file - even if you build the releases.

You can set this in the Advanced project property settings section.

Answer 4

Thanks for answers.

My problem was that I experienced sporadic crashes with the code, including the specified operator (access violation), however, without approval, the code was stable. But because of the answers, it seems like I should look better.