Problem with VS2005 Debugger

  • Thread starter Thread starter Rainer Queck
  • Start date Start date
R

Rainer Queck

Hi NG,

It looks like I have a problem with the debugger.
Running the current project every thing "looks" fine, but if I set a
breakpoint at a certain position in my code it takes the debugger very long
to stop there. Then, if I try to step forward in my code I get the following
error message (translated from German):

"There are no symbols for the call list frame. The source code can not be
displayed"

I hope I used the right translation german : "Aufruflistenrahmen" = "call
list frame"

What are the possible reasons to this problem?

Regards
Rainer Queck
 
.... found out more, which still does not help me...
as I tried to continue an other message came up :"LoaderLock was
recoginized"
Plus the help text wich is like : "A managed execution is tried within the
lockk for the OS-Loader..."

This still doesn't give me the idea, what I am doing wrong. Please give me
some hints on what to look for.

Regards
Rainer Queck
 
Hey Rainer,

Do you have a mixed assembly, ie C++ and C++/CLI or other managed code?
Then the following MSDN article about possible loader lock problems
might be interesting for you and explain what is happening.

http://msdn2.microsoft.com/en-us/library/ms173266(vs.80).aspx

I'm not aware of any other problem that could give this error. VS2005
has so-called MDA's (Managed Debug Assistents) which detect this (and
other) problems.

-- Freddy



Rainer Queck schreef:
 
Hello Freddy,

thanks for answering!

Freddy Potargent said:
Hey Rainer,

Do you have a mixed assembly, ie C++ and C++/CLI or other managed code?
Click to expand...
No, not that I would be aware of.

In the meanwhile I did some more down trace on the problem, and I found the
location, the problem starts.
In one of my classes, I create and start a thread from within the construcor
like this:

{
...
myThread = new Thread(new ThreadStart(myThreadMethod));
myThread.IsBackground = true;
myThread.Start();
}

If I put the breakpoint on "myThread.Start()" the debugger gets there right
away, no problems.
if I put the brreakpoint on "}" and a other one at the beginning of
"myThreadMethod" it takes the debugger long time to stop, and I get the
problem described on the beginning.

I hope this additional information helps to locate the cause of my problem!

Regards
Rainer Queck
 
[...]
If I put the breakpoint on "myThread.Start()" the debugger gets there
right
away, no problems.
if I put the brreakpoint on "}" and a other one at the beginning of
"myThreadMethod" it takes the debugger long time to stop, and I get the
problem described on the beginning.
Click to expand...

Don't know the answer. But the two really important questions that come
to mind are:

* Under what circumstances is your class instantiated? And,
* What exactly does the code in myThreadMethod do?

I'd be less concerned about the first error you reported (which seems like
a natural error to get stepping out of a constructor into code for which
you don't have symbols), and more concerned about the LoaderLock message,
which is usually telling you that you are trying to do some sort of
managed code thing from within a DLL's initialization code.

(Though, I will note that I know of at least one case where this MDA is
triggered, even though there is no apparent harm done)).

But without understanding better the circumstances surrounding the issue,
I'm doubtful you'll get much in the way of useful advice.

Pete
 
Hello Pete,

thanks for your respond!
Don't know the answer. But the two really important questions that come
to mind are:

* Under what circumstances is your class instantiated? And,
Click to expand...
I am not sure, on how you mean this question.
The callstack more ore less looks like for the ease I use names like
class1,class2,....myClass (the location of the problem):
MainForm.Form_Load event
-> aClass1.constructor
-> static aDecoratorClass.Instance()
-> aDecoratorClass.Constructor
-> static myClass.Instance()
-> myClass.Constructor
..... here as described in my last post, I create and start my
thread.
* What exactly does the code in myThreadMethod do?
Click to expand...
At the point, where I put my breakpoint, it has not yet done anything.
But without understanding better the circumstances surrounding the issue,
I'm doubtful you'll get much in the way of useful advice.
Click to expand...
I hope the shows the circumstance a little better. If not, please let me
know what else I can describe.

Regards
Rainer Queck
 
I am not sure, on how you mean this question.
Click to expand...

It's a very general question, with a potentially broad answer. You should
try to think about everything unique about your scenario. I know it
sounds like a lot, and it may be. But absent first-hand knowledge of your
code, it's not like anyone here can just infer the circumstances
ituitively.
The callstack more ore less looks like for the ease I use names like
class1,class2,....myClass (the location of the problem):
MainForm.Form_Load event
-> aClass1.constructor
-> static aDecoratorClass.Instance()
-> aDecoratorClass.Constructor
-> static myClass.Instance()
-> myClass.Constructor
..... here as described in my last post, I create and
start my thread.
Click to expand...

Well, that all looks a lot like a COM class factory. Whether that's what
you're doing or not, I still can't say. Knowing the call stack isn't
really the same as knowing what the circumstances are. But it's clear
that your code is not just simply instantiating a simple object.
At the point, where I put my breakpoint, it has not yet done anything.
Click to expand...

Your breakpoint is on the very first line of code in myThreadMethod?

One thing you might want to look at is whether turning off debugger
evaluation of class members helps. I don't actually remember the name of
the setting off the top of my head, but it will be found somewhere in the
options for the IDE, under the debug section. That feature normally works
fine, but I have certainly seen it cause the debugger to appear sluggish
in certain situations.

Pete
 
Hi Rainer,

Thanks for your feedback.

I agree with Pete that we need more information to understand why this
strange error is generated.

In addition to Pete's comment, is it possible for you to create a little
sample project to help us reproduce this problem locally? Once we can
reproduce this locally, it would be more efficient to debug it and
understand it.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
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.
 
Hi Pete, Hi Jeffrey,

thanks for your efforts on helping me.
I can understand, that it is very hard to find the reason for my problems,
not knowing the project its self.

Hoping the it might make things a little more clear, I copied a couple of
jpgs to my websit to give you a better impression:
http://www.qutronic.de/Temp/sqAdWinStartUp.jpg shows where the breakpoints
are and how I get there as a sequence diagram.

http://www.qutronic.de/Temp/csAdwinStartup.jpg shows the classes involved as
a class diagram.

http://www.qutronic.de/Temp/codeDecorator.jpg shows the code of the
"ADWinDecorator.Instance() mehtod.

http://www.qutronic.de/Temp/codeAdWinConstr.jpg shows the code, where the
thread is created.

http://www.qutronic.de/Temp/codeProcessAdwin.jpg shows the threadMethod with
its breakpoint.

Jeffrey, If this does not give enough information, I could zip the project
and send it to you.
I doubt that I will be able to generate a sample project that will show the
same effects.

Regards
Rainer Queck
 
Hey Rainer,

I now suspect the function evaluation of the debugger might be the
problem (as already suggested by Peter).

Try disabling func eval in the debugger: Tools -> Options -> Debugging
and uncheck the "Enable property evaluation and other implicit function
calls".

Under some circumstances only disabling the "Call ToString() on objects
...." also helps.

(Sorry, don't know how the options are called in German :-))

Note: the debugger (when it hits a breakpoint) tries to call properties
of the class to give more detailed info but this means that the debugger
not only fetches values of your class but actually *runs* parts of your
code after the breakpoint is hit. When using multiple threads this can
cause problems iff properties try to do something on another thread
since the debugger only allows the thread with the breakpoint to run.

I've also encountered this problem but never got a Loader Lock report
from the debugger. Usually the debugger takes a long time "to get to the
breakpoint" and then kills off the thread with the rest of the program
still running. The delay is caused because some property calls out to
another thread and/or blocks on another thread and the debugger is
waiting for it to finish.

HTH

-- Freddy



Rainer Queck schreef:
 
Hey Freddy, Hey Pete,


Freddy Potargent said:
Hey Rainer,

I now suspect the function evaluation of the debugger might be the problem
(as already suggested by Peter).

Try disabling func eval in the debugger: Tools -> Options -> Debugging and
uncheck the "Enable property evaluation and other implicit function
calls".
Click to expand...
That solves the problem right away. Thanks for this hint!

Is this now a "bug" in the Debugger, or is there the possibility of a
general not so ideal class design done by me, or in other words:
Is this something I am doing wrong?

Regards
Rainer
 
Rainer Queck schreef:
That solves the problem right away. Thanks for this hint!
Click to expand...

Glad it's solved now!
Is this now a "bug" in the Debugger, or is there the possibility of a
general not so ideal class design done by me, or in other words:
Is this something I am doing wrong?
Click to expand...

A bit of both I would say. ;-)

It's a very useful but *dangerous* feature of the debugger. The debugger
expects properties to be pure functions (ie no side-effects, always
return the same value when called with the same arguments, no visible
change of class state). A proper OO design will have only simple and
pure property getters and then you'll have no problems. But this is
easier said then done. :-)

Most problems happen in multi-threaded code but this can also bite you
in single threaded code when you have a property with side effects, for
instance a Next() property that returns a value *and* advances to the
next value. When the debugger calls your property (behind the scenes) to
display the value it also skips to the next one so *changing* the
meaning of your program.

Another problem is when you call functions on the main UI thread from a
property on another thread.

Or as already mentioned, when a property blocks on another thread.

Here are some blogs that dig deeper into the matter.
http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx
http://blogs.msdn.com/jmstall/archive/2005/03/23/400794.aspx

The big advantage is that you get more detailed info on your class when
debugging. Say eg you have a property that calculates some value based
on the current state of your class (ie a count of items in a collection
or the average value or a conversion from cartesian to polar coordinates
or ... ), the debugger will display the value immediately without you
having to calculate it from the class members.

Other (dangerous/evil) advantages are mentioned in the blogs. :-)

Also take a look at the System.Diagnostics.DebuggerDisplay,
DebuggerHidden, ... attributes. You can use these to guide the debugger
away from dangerous properties while keeping the better debug displays
for safe properties.

Have fun,

-- Freddy
 
Hey Freddy,

thank you very much for your detailed explanations!
I think I start to understand, where the problem is.
I'll have to do a little more reading on that subject.

Thanks for your help!

Regards
Rainer
 
Hi Rainer,

Oh, glad to see turning off the property/function evaluation can resolve
this problem. This thread appears as informative to me either. I will add
this issye to my information list so that if we meet strange behavior in
future we can give this a consideration.

Freddy, thank you for sharing with the community!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
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.
 
My pleasure! :-)

I have also got quite some interesting info from this NG just from
lurking so now when I have a chance to reverse the "dataflow" I'll do
it, when time permits of course. :-)

Kind regards,

-- Freddy


Jeffrey Tan[MSFT] schreef:
 
A proper OO design will have only simple and pure property getters
Click to expand...

The only OO design characteristic I think fits here is encapsulation, and
that would say that whether a property access has side-effects is completely
up to the owner of the property.

///ark
 
* Mark Wilden wrote, On 29-6-2007 20:45:
The only OO design characteristic I think fits here is encapsulation, and
that would say that whether a property access has side-effects is completely
up to the owner of the property.
Click to expand...

If a property is dangerous in the way that it has altering behavior on
it's getter, you can mark it to hide it from the debugger altogether.

Jesse
 
I agree with you Mark to some point. I try to avoid property getters
with observable side effects, like a "get and advance" property. Those
I usually split in a pure getter and a "command" Next() that advances to
the next item.

The base libraries also use this idiom, see for instance enumerators
where you have a "Current" property and a void "MoveNext()" command.

A property that changes internal state but has no observable effect is
used more often. For instance on first access of some "expensive"
property a value is fetched/calculated and cached. This will not change
the external view of your class but you must expect that during
debugging the cached values *can* be calculated or fetched at different
moments then running stand-alone.

A fun one is having logging active in a property getter, safe but
your logs can look strange (filled with unexpected entries) after a
debugging session. :-)

But I agree that it's sometimes useful to have a property with *real*
side-effects and like Jesse pointed out, you can hide or sanitize these
for the Debugger using the
DebuggerBrowsable(DebuggerBrowsableState.Never)
DebuggerHidden()
DebuggerDisplay("some safe info about the property")
attributes.

An example of an "get and advance" property is a UniqueID class. The
class is responsible to never return the same ID twice so encapsulation
requires a property with side-effects. :-) You could also argue that in
this case you don't make a property but a function NextID() to make it
clear it's not *just* a property.

-- Freddy


Jesse Houwing schreef:
 
It may or may not be a good idea for property access not to have side
effects. I was just saying that I didn't see any OOP reason for doing it.

///ark
 
Back
Top