I am using Visual Studio 2005 to build a console application that fetches
data from an external web service
When I debug through the project and watch the values in the return
object,
I always get the following error:
"Cannot evaluate expression because a thread is stopped at a point where
garbage collection is impossible, possibly because the code is optimized"
I know for sure that the values are being correctly returned by the web
service as I can see it when I capture using Fiddler.
Couldn't find any useful help on this error, any pointers in the right
direction is really appreciated.
My knowledge of that error is somewhat vague and tangential. But you
asked for "any pointers", so here goes...
The error sounds to me as though the debugger itself is limited as to what
it's capable of doing at that point in the code, because of some inability
for it to use the garbage collector in a particular way.
The JIT compiler, as it generates the code, can keep track of certain
places in the code where it's okay to suspend a thread and let the GC
run. I've never seen that error with a "debug" build, which makes me
think that in a debug build, the compiled code can be suspended pretty
much at each statement.
But I can believe that in a "release" build, it's possible to put a
breakpoint or otherwise interrupt a thread at a point where the JIT
compiler has noted the thread as not being a suitable place to be
suspended for the purpose of garbage collection. If the debugger then
requires the ability to actually run a garbage collection (for example,
maybe it uses managed code as well in the evaluation of the expression,
but wants to ensure that whatever it allocates on the heap is freed before
the thread is resumed), then if the code's stopped at a point where
garbage collection isn't allowed, it won't let you do whatever operation
requires garbage collection.
I don't know if there's a way to explicitly control what regions of your
code allow garbage collection. But if there is, doing so in order to
ensure that the point in the code where you want to stop and look at the
expression that otherwise can't be evaluated might resolve the issue.
If there's no explicit way, I suppose it's possible there are things you
can put in that have the side-effect of allowing garbage collection. For
example, I would expect a call to Thread.Sleep() to force the JIT compiler
to make that part of the code collection-safe. I'd guess the value you
pass to the method wouldn't matter, but if passing 0 doesn't work, you
might try passing 1 or even something larger. Another possible
alternative might be to put an explicit call to Debugger.Break() (maybe
protecting the call with an if() statement using a variable you can
control, so that you don't _have_ to always break there).
Finally, of course, if it's possible to correctly debug whatever issue
you're trying to look at with a "debug" build instead of a "release"
build, that may be the easiest fix of all.
Of course, if my theory is wrong, none of the above is useful. Sorry if
that's the case.
Pete
