stacktrace and release mode - interesting problem

  • Thread starter Thread starter Iain Mcleod
  • Start date Start date
I

Iain Mcleod

put the following into a console app in .net 2.0, compile it in release mode
and then run it 2 ways:
through visual studio (works as expected)
now double click the console app via windows explorer.

This crashes with a null reference exception because the stacktrace only
contains one frame [it still thinks it's in sub Main()].

This seems to be a problem with release mode and compiler optimisations:
http://www.thescripts.com/forum/thread494282.html[^]


My question:
Is there any SAFE way to get the calling method's methodinfo object?


Thanks in advance
Iain


Module Module1

Sub Main()
TestFunction()
Console.ReadLine()
End Sub

Private Sub TestFunction()
PrintStackTrace()
End Sub

Private Sub PrintStackTrace()
Console.WriteLine(New StackTrace().GetFrame(1).GetMethod().Name)
End Sub

End Module
 
Iain said:
put the following into a console app in .net 2.0, compile it in release mode
and then run it 2 ways:
through visual studio (works as expected)
now double click the console app via windows explorer.

This crashes with a null reference exception because the stacktrace only
contains one frame [it still thinks it's in sub Main()].

This seems to be a problem with release mode and compiler optimisations:
http://www.thescripts.com/forum/thread494282.html[^]
Click to expand...

I don't understand your question. The link you provided includes clear
replies explaining that the issue is due to inlining and is not a
problem (except of course if you are writing code that doesn't take
inlining into account).

In C#, there's a code attribute that can be used to suppress inlining
for specific methods. I don't know if VB has something similar, but if
it does, then that would be the solution to your problem.

Otherwise, don't write code that assumes a method won't be inlined.

Pete
 
You could likely test the number of frames to take into account possible
optimizations.

IMO your best is first to explain what you are trying to do...
 
Thanks Peter

This is exactly the attribute I was looking for:
<MethodImpl(MethodImplOptions.NoInlining)>

You're perfectly correct as well. You should never write code that relies
on inlining not taking place. Sadly my colleague who wrote a reflection
based data access layer had never heard of inlining until yesterday.
In fact, the project containing the offending data access layer had been in
production in release mode but in a web project - so obviously no inlining
was taking place. It was only when I reused the data access library in a
console app that the problem manifested itself.

I'm sure we're not the first to have fallen victim to this unpredictability.

Cheers
Iain
Peter Duniho said:
Iain said:
put the following into a console app in .net 2.0, compile it in release mode
and then run it 2 ways:
through visual studio (works as expected)
now double click the console app via windows explorer.

This crashes with a null reference exception because the stacktrace only
contains one frame [it still thinks it's in sub Main()].

This seems to be a problem with release mode and compiler optimisations:
http://www.thescripts.com/forum/thread494282.html[^]
Click to expand...

I don't understand your question. The link you provided includes clear
replies explaining that the issue is due to inlining and is not a
problem (except of course if you are writing code that doesn't take
inlining into account).

In C#, there's a code attribute that can be used to suppress inlining
for specific methods. I don't know if VB has something similar, but if
it does, then that would be the solution to your problem.

Otherwise, don't write code that assumes a method won't be inlined.

Pete
Click to expand...
 
Back
Top