Debugging code being run during garbage collection?

[Brian]

What's the best way to debug code that is being run during garbage
collection?

We are getting AccessViolationExceptions that seem to be happening
during garbage collection. But when it hits the debugger, it is at whatever
line of code the main thread was at when the garbage collector decided to
run. In other words, the debugger is in irrelevant code.

In general, if you have bugs in Dispose or finalization methods, what's the
best way to debug such?

 

[Marc Gravell]

Well, GC doesn't run Dispose(); only finalize.

And you shouldn't be touching any other objects except "this" in a
finalizer; the idea is to release unmanaged resources, such as Win32
handles that only exist as an int/IntPtr/etc.

You shouldn't touch any other object in a finalizer; it might not really
be there...

Marc

 

[Brian]

Well, GC doesn't run Dispose(); only finalize.

And you shouldn't be touching any other objects except "this" in a
finalizer; the idea is to release unmanaged resources, such as Win32
handles that only exist as an int/IntPtr/etc.

You shouldn't touch any other object in a finalizer; it might not really
be there...

I understand. And actually, I try not to write finalizers at all anyway.
But we use .NET WinForms and embed Office in our app using DSO Framer.
So, we use code that Microsoft has written that has finalizers.

And, yes, it might not really be there. But I added a debug command that
just invokes System.GC.Collect. After doing certain things in our app, if
I invoke that command, then I get the AccessViolationException. Its
possible
that its a timing thing and it was just a really really "lucky" coincidence.

Any suggestions on how to get an idea of what object's finalizer is causing
that would be GREATLY appreciated.

Brian

 

[Willy Denoyette [MVP]]

What's the best way to debug code that is being run during garbage
collection?

We are getting AccessViolationExceptions that seem to be happening
during garbage collection. But when it hits the debugger, it is at
whatever
line of code the main thread was at when the garbage collector decided to
run. In other words, the debugger is in irrelevant code.

In general, if you have bugs in Dispose or finalization methods, what's
the
best way to debug such?

User threads are stopped when the GC kicks-in, it's only when the finalizer
thread runs (after a GC run) that user code can continue to run, this
because finalize methods do run on a separate (the finalizer) thread. The GC
itself will not throw an AV,only the finalize method can possibly throw an
AV exception, this is mostly due to a failure in native interop (COM or
PInvoke) code. The only way to debug such failures is by attaching the
program to a debugger when the failure occurs.

Willy.

 

[Steven Cheng [MSFT]]

Hi Brian,

I agree with Willy's suggestion. Normally after GC, the finializers will be
called by the finializer threads. It is likely that something that is
disposed in finializer result to the AV error. And for such exception, it
maybe hard to debug through break statically in source code. As Willy
mentioned, you can use debugger to attach the process and waitign for the
exception point. The windbg(debugging tools for windows) is a common
debugger for production environment debugging(crash, hang ,high cpu...).
Here is some reference introducing it:

#Production Debugging for .NET Framework Applications
http://msdn2.microsoft.com/en-us/library/ms954594.aspx

#.NET Debugging Demos - Information and setup instructions
http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-i
nstructions.aspx

#A word for WinDbg (2)
http://mtaulty.com/communityserver/blogs/mike_taultys_blog/archive/2004/08/0
3/4671.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Brian]

The windbg(debugging tools for windows) is a common
debugger for production environment debugging(crash, hang ,high cpu...).
Here is some reference introducing it:

Thanks for those links! They will prove useful, I'm sure.


We did find the problem... and since I suspect others have this problem... I
thought I'd document it here...

Many of the posts on the net about AccessViolationExceptions have a stack
trace similar to some of ours... coming out of the ToolTip code, which
evidently uses some Unsafe code underneath (based on the naming of their
functions). Given we see the violation show up in a variety of places, we
did not give any significance to any of them. However, it seems that the
ToolTip stuff is the unsafe code that was causing the problem. We removed
it from the panel in question, and the AccessViolationException has
vanished.

Searching the net further for that pair shows a LOT of people with
AccessViolations appearing in that ToolTip code, but seemingly nobody is
putting the blame on that ToolTip code. If anyone does a search on that and
gets this note, my recommendation: try removing the ToolTip code, might fix
the problem.

Hope that helps any others with this problem.

 

[Willy Denoyette [MVP]]

Thanks for those links! They will prove useful, I'm sure.


We did find the problem... and since I suspect others have this problem...
I thought I'd document it here...

Many of the posts on the net about AccessViolationExceptions have a stack
trace similar to some of ours... coming out of the ToolTip code, which
evidently uses some Unsafe code underneath (based on the naming of their
functions). Given we see the violation show up in a variety of places, we
did not give any significance to any of them. However, it seems that the
ToolTip stuff is the unsafe code that was causing the problem. We removed
it from the panel in question, and the AccessViolationException has
vanished.

Searching the net further for that pair shows a LOT of people with
AccessViolations appearing in that ToolTip code, but seemingly nobody is
putting the blame on that ToolTip code. If anyone does a search on that
and gets this note, my recommendation: try removing the ToolTip code,
might fix the problem.

Hope that helps any others with this problem.

This might help you forward, but it's not a fix.
Please post your code, this would be more helpful than simply asking other
to removing this from their application code.
Note that tooltip doesn't use "unsafe" code, it calls into unmanaged code,
but this shouldn't be an issue unless there is a bug in the tooltip managed
code or in the unmanaged code called from tooltip.

Willy.

 

[Brian]

This might help you forward, but it's not a fix.
Please post your code, this would be more helpful than simply asking other
to removing this from their application code.
Note that tooltip doesn't use "unsafe" code, it calls into unmanaged code,
but this shouldn't be an issue unless there is a bug in the tooltip
managed code or in the unmanaged code called from tooltip.

Uhh, I understand. Yes, I am suggesting there is a bug in the ToolTip
code that results in AccessViolationExceptions under certain conditions.
Its not my code... so I can't fix it... or debug it... or post it.

I have added a work item to our TFS to attempt to create an isolated
example that we can send to Microsoft. But not knowing the conditions
that exercise the bug in the ToolTip code, its a bit hard. Early attempts
have failed. And we have higher priorities at the moment.

However, if you do a search on "AccessViolationException ToolTip"
you will find numerous cases. If I remember right, some of those
posted code that may have it isolated. I would suggest examining those;
in fact, that may be easier than trying to isolate it out of our code.


Brian

 

[Steven Cheng [MSFT]]

Hi Brian,

Thanks for your follow-up and sharing the result with us.

Yes, it may required much more to get the detailed root cause or fix it
since the problem may reside deep in the underlying code. Anyway, if you
have simple typical code that can repro it, I recommend you submit the
problem to our feedback site:

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
x.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

Subject: Re: Debugging code being run during garbage collection?
Date: Sat, 12 Apr 2008 08:06:29 -0500

 

[Brian]

Thanks for your follow-up and sharing the result with us.

Yes, it may required much more to get the detailed root cause or fix it
since the problem may reside deep in the underlying code. Anyway, if you
have simple typical code that can repro it, I recommend you submit the
problem to our feedback site:

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

FWIW, we did manage to construct an isolated code project that
reproduces the issue. I looked at that "Connect" feedback site...
not sure where I'd submit something there... but I did submit it
to the support email address for certified partners. They should
get it to the right people.

Brian