Garbage Collection error

  • Thread starter Thread starter Vijay
  • Start date Start date
V

Vijay

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.

Thanks!
 
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
 
The weird thing is that when the same application is run without any
breakpoints in the code or when it is run in release mode, it executes
without any issues.

Anyways, I tried both the Thread.Sleep and Debugger.Break approach and
neither of them worked for me.

I will keep digging or find alternative ways

Thanks for the help Pete
 
The weird thing is that when the same application is run without any
breakpoints in the code or when it is run in release mode, it executes
without any issues.

I'm not sure what that means. From your description, it sounds as though
all you're running into is a debugger limitation. I would of course not
expect that limitation to have any effect whatsoever as long as you're not
trying to interact with the application using the debugger.

When you write "or when it is run in release mode", does that mean that
even if you do set a break point, as long as the build is a "release"
build you can evaluate whatever expression it is you're trying to evaluate?

Keep in mind: it's the _build_ that is either "debug" or "release" mode.
I can't tell from your post whether you understand this or not, so I want
to make sure you do. In the IDE, it'll run whatever version is the
current build setting, but otherwise it's a matter of which compiled
executable you run, and not a matter of setting some mode at run-time.
Anyways, I tried both the Thread.Sleep and Debugger.Break approach and
neither of them worked for me.

Sorry to hear that.
I will keep digging or find alternative ways

Thanks for the help Pete

Sorry I didn't have any good suggestions. For what it's worth, given the
lack of other replies, I suspect this isn't something that people run into
commonly. If you want help, you really should create a
concise-but-complete sample of code that reliably demonstrates the
problem. Without seeing the behavior firsthand, it's pretty much
impossible for someone unfamiliar with the problem to offer advice. Being
able to see the behavior firsthand, it's possible that someone who's never
seen it but who is reasonably familiar with the IDE might be able to at
least explain what's going on, if not offer a useful workaround.

Noting the high importance on both "concise" (don't include anything
that's not absolutely necessary to reproduce the problem) and "complete"
(make sure the sample can be compiled and run without any work other than
to copy it locally to a place where it can be compiled).

Pete
 
Back
Top