I remember seeing somewhere that you can specify which dll to get the address of symbols so that one can use that variable in the watch window. I can't for the life of me remember where I saw this. The best that I can come up with is Format Specifiers in C++.
The reason I want this is so that I can see the visibility status of a window and MSVS keeps saying that identifier "IsWindowVisible" is undefined.
I was trying to use something like the following in the watch window:
::IsWindowVisible(m_hWnd),user32.dll
Using:
this->IsWindowVisible()
results in Function CWnd::IsWindowVisible has no address, possibly due to compiler optimizations. which is why I'm trying to use the win32 call. Ideas?
http://msdn.microsoft.com/en-nz/library/y2t7ahxk.aspx
Haven't tried it, but it seems to me that IsWindowVisible(m_hWnd) should work, or maybe IsWindowVisible(this->m_hWnd).
Related
I've been trying for weeks now to get lldb working with C++11 on Mavericks, and I just cannot get it working reliably. Has anyone managed this? What exact steps did you take?
Symptoms I find include:
(1) Unable to invoke basic std functions, like if I have a vector v in the code, I cannot call "v.size()" (earlier StackOverflow responses agreed with this).
(2) Generally gets confused all the time about data types and classes. Sometimes it understands simple things, sometimes it just gives odd error messages, and misinterprets user types.
(3) If I stop the code and call a bunch of other functions, lldb sometimes just gets very confused, and I have seen utterly bizarre run-time behavior (e.g., I call a function from lldb and get logically impossible results, as if the call stack or memory was somehow mangled).
(4) Sometimes lldb just gives up and seems to lose track of where it is on the stack.
I know these are vague, but has anyone used lldb extensively for expression evaluation (not just breakpoints, but calling functions and methods from with debugger) and had lldb work? I have these very complex, very large datastructures and need an interactive debugger to manipulate them, and invoke methods on them, interactively (i.e., a repl).
Not part of the question, but if anyone knows of a true C++11 debugger that can call methods and evaluate functions at run time interactively, and works reliably on MacOS Mavericks, I'd be very grateful.
N.B. earlier MacOS versions are entirely different from Mavericks.
I don't know about 2-4, they are not specific enough to really tell. But #1 turns out to be a problem with the new C++ standard library on OS X. It is pretty aggressive about inlining most of the std::* functions, and not creating out of line copies. That's actually usually exactly what you want, but it is inconvenient for debugging!
You usually see errors like:
(lldb) expr my_vec.size()
error: call to a function 'std::__1::vector<int, std::__1::allocator<int> >::size() const' ('_ZNKSt3__16vectorIiNS_9allocatorIiEEE4sizeEv') that is not present in the target
And that's because there is no function to call, there's only inlined versions sprinkled through-out your code.
In C++11 you can work around this if you know in advance you will want to call functions in some particular template class by putting:
template class std::vector<int>;
for instance, in you code somewhere. Probably want to do this inside some kind of #ifdef DEBUG construct, you wouldn't want to ship code this way.
I'm using XCode to debug some code. Specifically, the code that I'm debugging exposes a float[][] as float**. I am unable to change this syntax, but I'm not certain it would help anyway.
After including a relevant breakpoint, I want to view the contents of the array in the Variables view of the debugger?
When I double-click on the variable in the list of Autos, I see that I can add a Summary Format which seems deceivingly like it might help, but for the life of me, I can't figure out how to use it!
In conclusion, how do I use the Variables View to see the contents of my array of arrays of this primitive type without resorting to typing commands directly to GDB (which, I believe, can also perform this function)?
CreateFile for example. When I get INVALID_HANDLE_VALUE, what are all the possible values that can be returned by GetLastError? MSDN doesn't say. It mentions some and I can guess others, but how (if at all) can I be sure that my switch statement will never reach default?
Such a list doesn't exist and in fact you can't ever have such a list. In some future version of Windows a function may well start returning an error code that did not exist when you compiled your program.
The standard way to deal with this is handle any error codes that you know about that need special treatment, and let all others fall through to a default handler. Call FormatMessage() to get a descriptive text string for the error.
I am trying to track down a non-exhaustive pattern in a libraries code. Specifically HDBC's mysql implementation. It is trying to match over types in my program and map them to mysql's types I believe. I can't seem to get a callstack for this error which means that since there are a number of parameters to the SQL query it is difficult to track down exactly what is causing it.
Is it possible to get a callstack in haskell so I would know which parameter was causing the error? Also I would think that this should be caught by the compiler since it should be able to look at my types and the patterns and make sure that there was a corresponding match.
You can use the GHCi debugger to identify where the exception is coming from.
I walk through a full example here.
You might also take a look at the Debug.Trace library.
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.