Problem with VS2005 Debugger

[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

[Rainer Queck]

Hello Freddy,

thanks for answering!

"Freddy Potargent" <fr**************@amcnv.beschrieb im Newsbeitrag
news:dI******************@phobos.telenet-ops.be...

Hey Rainer,

Do you have a mixed assembly, ie C++ and C++/CLI or other managed code?

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

[Freddy Potargent]

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/lib...66(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:

... 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

[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

[Jeffrey Tan[MSFT]]

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/subscripti...ult.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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Rainer Queck]

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

""Jeffrey Tan[MSFT]"" <je***@online.microsoft.comschrieb im Newsbeitrag
news:Xu**************@TK2MSFTNGHUB02.phx.gbl...

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/subscripti...ult.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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Freddy Potargent]

Rainer Queck schreef:

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

That solves the problem right away. Thanks for this hint!

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?

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...18/494648.aspx
http://blogs.msdn.com/jmstall/archiv...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

[Rainer Queck]

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

[Jeffrey Tan[MSFT]]

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/subscripti...ult.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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Freddy Potargent]

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:

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!

[Mark Wilden]

"Freddy Potargent" <fr**************@amcnv.bewrote in message
news:9q*******************@phobos.telenet-ops.be...

>A proper OO design will have only simple and pure property getters

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

[Jesse Houwing]

* Mark Wilden wrote, On 29-6-2007 20:45:

"Freddy Potargent" <fr**************@amcnv.bewrote in message
news:9q*******************@phobos.telenet-ops.be...

>A proper OO design will have only simple and pure property getters

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.

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

[Freddy Potargent]

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:

* Mark Wilden wrote, On 29-6-2007 20:45:

>"Freddy Potargent" <fr**************@amcnv.bewrote in message
news:9q*******************@phobos.telenet-ops.be...

>>A proper OO design will have only simple and pure property getters

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.

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

[Mark Wilden]

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