System.Diagnostics.StackTrace is wrong sometims

  • Thread starter Thread starter Zytan
  • Start date Start date
Z

Zytan

I use System.Diagnostics.StackTrace to get the stack trace of the
current function, to print out the function's name to the log, and
sometimes it shows that a function that doesn't even write to the log
is what is writing to the log. This just can't be, so
System.Diagnostics.StackTrace must be returning the wrong information
(from another thread, i suppose).

Is this normal, or expected? Can it be reliable?

Zytan
 
I doubt it. What's more than likely is you are not synchronizing access
to the log, so you are writing stack traces that are intermingled with each
other.

What you need to do is synchronize access to the log file, writing out
the stack traces, or, have some sort of correlation id associated with each
stack trace that you write, which will allow you to group all the
information later.
 
Nicholas Paldino said:
I doubt it. What's more than likely is you are not synchronizing
access to the log, so you are writing stack traces that are intermingled
with each other.
Click to expand...

I doubt that the StackTrace is wrong too. However, Zytan's point is that
function names wind up in the log that should *never* be in the log. It's
not that they're in the wrong order. It's that they should just never
appear at all.

For that, I have no explanation.

Zytan, if you can provide a concise example of code that reliably reproduces
the problem, that would be helpful.

Pete
 
I doubt it. What's more than likely is you are not synchronizing access
to the log, so you are writing stack traces that are intermingled with each
other.
Click to expand...

That is likely. I am using TextWriter, which is synchronized, but if
I make two calls to my LogWrite function, then they could get mixed
up. The problem is that I can see when such a thing happens, and my
issues occur so often, it must be something else. Although, your
point is taken, and I'll solve this issue ANYWAY, even though it
hardly happens, to remove that as a possibility.

I'll reply to Peter's post with what I think is the real issue...

thanks,
Zytan
 
I doubt that the StackTrace is wrong too.

I know, how can it be wrong, when so many people use it?
However, Zytan's point is that
function names wind up in the log that should *never* be in the log. It's
not that they're in the wrong order. It's that they should just never
appear at all.

For that, I have no explanation.
Click to expand...

I have narrowed the issue down:

It works perfectly, always, in debug mode.
It doesn't work, in release mode.

I MAY have deleted the .pdb files from the release mode directory for
EACH time this issue occurred. Would that cause this to happen?
Would it be left to guess (incorrectly) without the PDB?

Zytan
 
Since I cannot see my own post yet, due to Google Groups being REALLY
slow the past 2 days, I will append here:

I have the PDB file in the release directory of my program, and the
bug still occurs. So, the presence or lack of the PDB file is not
what is causing this.

I'll try and make a small program that shows the error, and maybe I'll
solve this myself in the process.

Zytan
 
System.Diagnostics.StackTrace callStack = new
System.Diagnostics.StackTrace();

returns different information whether you're in debug or release mode.

Zytan
 
(I still cannot see any additional posts to this thread, including my
own so I'll post my results here)

I have a GetCallStack() function that just calls:
x = new System.Diagnostics.StackTrace();
and extracts the stack from x, and returns it as a string.

When I call this from Main(), I get:

// DEBUG: ThreadHelper.ThreadStart() --> ExecutionContext.Run() -->
ThreadHelper.ThreadStart_Context() --> HostProc.RunUsersAssembly() -->
AppDomain.ExecuteAssembly() --> AppDomain.nExecuteAssembly() -->
Program.Main() --> Program.GetCallStack()
// RELEASE: Program.Main() --> Program.GetCallStack()

Note the last two in the stack are similar.
But, when I call this function from inside a class function, that
Main() calls:

// DEBUG: ThreadHelper.ThreadStart() --> ExecutionContext.Run() -->
ThreadHelper.ThreadStart_Context() --> HostProc.RunUsersAssembly() -->
AppDomain.ExecuteAssembly() --> AppDomain.nExecuteAssembly() -->
Program.Main() --> MyClass.MyFunc() --> Program.GetCallStack()
// RELEASE: Program.Main() --> Program.GetCallStack()

Note the last 2/3 of each one is different. MyClass.MyFunc() is no
where to be found in the release build!!!

Zytan
 
Zytan said:
[...]
It works perfectly, always, in debug mode.
It doesn't work, in release mode.

I MAY have deleted the .pdb files from the release mode directory for
EACH time this issue occurred. Would that cause this to happen?
Would it be left to guess (incorrectly) without the PDB?
Click to expand...

Can you post a short sample of code that displays a correct stack trace when
compiled as Debug and an incorrect stack trace when compiled as Release?

Pete
 
Zytan said:
[...]
Note the last two in the stack are similar.
But, when I call this function from inside a class function, that
Main() calls:

// DEBUG: ThreadHelper.ThreadStart() --> ExecutionContext.Run() -->
ThreadHelper.ThreadStart_Context() --> HostProc.RunUsersAssembly() -->
AppDomain.ExecuteAssembly() --> AppDomain.nExecuteAssembly() -->
Program.Main() --> MyClass.MyFunc() --> Program.GetCallStack()
// RELEASE: Program.Main() --> Program.GetCallStack()

Note the last 2/3 of each one is different. MyClass.MyFunc() is no
where to be found in the release build!!!
Click to expand...

Ah. Is it possible that the automatic function inlining built into C# is
causing your function to just "disappear"? It won't show up in a stack
trace if it no longer exists.

Pete
 
Ah. Is it possible that the automatic function inlining built into C# is
causing your function to just "disappear"? It won't show up in a stack
trace if it no longer exists.
Click to expand...

I've just checked, and for that to happen, it needs to miss TWO
functions in the chain, but they ARE in the same call stack. And
these functions are not small functions! But, at least this explains
what is happening...

Unfortunately, it makes the call stack rather useless to determine
what the current function is...

Zytan
 
Can you post a short sample of code that displays a correct stack trace when
compiled as Debug and an incorrect stack trace when compiled as Release?
Click to expand...

static void Main(string[] args)
{
MyFunc();
Console.ReadKey(false);
}

public static void MyFunc()
{
Console.WriteLine(Program.GetCallStack());
}

public static string GetCallStack()
{
System.Diagnostics.StackTrace callStack = new
System.Diagnostics.StackTrace();
string s = "";
int index = 0;
while (true)
{
System.Diagnostics.StackFrame frame =
callStack.GetFrame(index);
if (frame == null) break;
System.Reflection.MethodBase method = frame.GetMethod();

if (index > 0) s = " --> " + s;
s = method.DeclaringType.Name + "." + method.Name + "()" + s;
index++;
}
return (s);
}

Zytan
 
Ah. Is it possible that the automatic function inlining built into C# is
causing your function to just "disappear"? It won't show up in a stack
trace if it no longer exists.
Click to expand...

Pete, I think I solved the issue.

My functions were large, so they were NOT being deleted from the call
stack, but..... my WriteFunction() function which my function call is
tiny. AND, it has to take measures to not print ITSELF when its
caller is asking "who am I?". So, it counts to skip itself where it
expects to be in the call stack. In release mode, since it is so
small, it gets ejected from the call stack, and thus when it chooses
to skip itself, it's really skipping the function name that I wanted!
And, furthermore, because this WriteFunction() is a wrapper, and not
the real deal, they are likely BOTH ejected from the release call
stack, which explains why TWO of my treasured functions are missing
from the display!

NOW, for the solution to this mess...

Zytan
 
Back
Top