How can I find out the address of a variable on the stack in the visual studio debugger watch window (or elsewhere?)
Reading the variable works fine:
streets streets [11790](0x1c66a690 [...] std::vector<Street *,std::allocator<Street *> >
But prefixing with & doesn't give me an address:
&streets streets [11790](0x1c66a690 [...] std::vector<Street *,std::allocator<Street *> >
Also, trying to read the size doesn't work, why is that?
streets.size() CXX0075: Error: Cannot set up Function Evaluation
The program is compiled in debug mode.
The Visual Studio Debugger drives debugger watch, quick-watch, auto, and local variable views through a translation defined by schema in a file called autoexp.dat (depending on your VS version, the content therein can vary markedly). The file is located in your VS-InstallDir/Common7/Packages/Debugger folder (at least it is for VS2010 and VS2012).
Knowing this, a couple of ideas for you to try/consider:
Method One: Library Know-How
To access the actual address of the first element within the vector I ultimately just do this:
streets._Myfirst
if you know the number of elements you're going to view, you can use the array-expansion extension by:
streets._Myfirst,N
where N is the number of elements
Note: this only works as shown above with vectors. The practice is different depending on which container you are using. There are no-doubt simpler ways that are probably less dependent on the implementation of std::vector<>, but this is the simplest wasy I know how to get you up and debugging quickly.
Method Two: Scorched Earth
Under Tools/Options/Debugging/General is a list of features you can switch on and off. One of them you will find particularly useful to this question:
Show raw structure of objects in variable windows.
Turn this ON to see raw member variables of all structures and containers, including standard containers like std::vector<>. This effectively disables usage of the templates in autoexp.dat
To see the address, cast to a void *, like so: (void *)&streets.
This is Visual Studio's attempt to be helpful by showing you the pointed-to vector directly. A similar problem affects arrays of vectors.
Related
I have a crash dump which I'm trying to analyze (VC++ 2010).
I then have a callstack that looks like this (I've trimmed a lot here for readability):
myapp.exe!std::_Tree<std::_Tmap_traits<unsigned int,StructB,std::less<unsigned int> ... >::_Erase(...)
myapp.exe!std::_Tree<std::_Tmap_traits<unsigned int,StructA,std::less<unsigned int>,... >::clear()
(clear() calls _Erase() )
Note the difference in the template parameter of the value (StructA vs. StructB).
Now, I know different methods which have exactly the same binary can have the same symbol in the PDB even though they actually use different code.
I assume this is the case here (std::map::_Erase is the same no matter the value type).
But how can I know? Is there a list of stl methods (for this MS implementation) for which this applies?
Is it possible it's some sort of a bug?
Update:
Looking into the PDB (in a text editor), I see many std::map<...>::_Erase, and specifically I see them for both StructA and StructB. I don't know if it means anything about the folding.
In addition, the disassembled code of std::map shows a call to an address which is interpreted as std::map.
I guess this mean code folding...
You can use /OPT:NOICF to disable the code folding behavior.
http://msdn.microsoft.com/en-us/library/bxwfs976%28v=vs.80%29.aspx
Well, I ended up rebuilding with creating a map file.
In the map file I can see that both methods (_Erase for StructA and _Erase for StructB) have the same address.
So it's not a bug.
class SomeClass
{
//some members
MemberClass one_of_the_mem_;
}
I have a function foo( SomeClass *object ) within a dll, it is being called from an exe.
Problem
address of one_of_the_mem_ changes during the time the dll call is dispatched.
Details:
before the call is made (from exe):
'&(this).one_of_the_mem_' - `0x00e913d0`
after - in the dll itself :
'&(this).one_of_the_mem_' - `0x00e913dc`
The address of object remains constant. It is only the member whose address shift by c every time.
I want some pointers regarding how can I troubleshoot this problem.
Code :
Code from Exe
stat = module->init ( this,
object_a,
&object_b,
object_c,
con_dir
);
Code in DLL
Status_C ModuleClass( SomeClass *object, int index, Config *conf, const char* name)
{
_ASSERT(0); //DEBUGGING HOOK
...
Update 1:
I compared the Offsets of members following Michael's instruction and they are the same in both cases.
Update 2:
I found a way to dump the class layout and noticed the difference in size, I have to figure out why is that happening though.
linked is the question that I found to dump class layout.
Update 3:
Final Update : Solved the problem, much thanks to Michael Burr.
it turned out that one of the build was using 32 bit time, _USE_32BIT_TIME_T was defined in it and the other one was using 64 bit time. So it generated the different layout for the object, attached is the difference file.
Your DLL was probably compiled with different set of compiler options (or maybe even a slightly different header file) and the class layout is different as a result.
For example, if one was built using debug flags and other wasn't or even if different compiler versions were used. For example, the libraries used by different compiler versions might have subtle differences and if your class incorporates a type defined by the library you could have different layouts.
As a concrete example, with Microsoft's compiler iterators and containers are sensitive to release/debug, _SECURE_SCL on/off , and _HAS_ITERATOR_DEBUGGING on/off setting (at least up though VS 2008 - VS 2010 may have changed some of this to a certain extent). See http://connect.microsoft.com/VisualStudio/feedback/details/352699/secure-scl-is-broken-in-release-builds for some details.
These kinds of issues make using C++ classes across DLL boundaries a bit more fragile than using straight C interfaces. They can occur in C structures as well, but it seems like C++ libraries have these differences more often (I think that's the nature of having richer functionality).
Another layout-changing issue that occurs every now and then is having a different structure packing option in effect in the different compiles. One thing that can 'hide' this is that pragmas are often used in headers to set structure packing to a certain value, and sometimes you may come across a header that does this without changing it back to the default (or more correctly the previous setting). If you have such a header, it's easy to have it included in the build for one module, but not another.
that sounds a bit wierd, you should show more code, it should 'move' if it being passed by ref, it sounds more like a copy of it is being made and that having the member function called.
Perhaps the DLL versions is compiled against a different version that you are referencing. check and make sure the header file is for the same version as the dll.
Recompile the library if you can.
I am occasionally getting odd behavior from boost::lower, when called on a std::wstring. In particular, I have seen the following assertion fail in a release build (but not in a debug build):
Assertion failed: !is_singular(), file C:\boost_1_40_0\boost/range/iterator_range.hpp, line 281
I have also seen what appear to be memory errors after calling boost::to_lower in contexts such as:
void test(const wchar_t* word) {
std::wstring buf(word);
boost::to_lower(buf);
...
}
Replacing the calls boost::tolower(wstr) with std::transform(wstr.begin(), wstr.end(), wstr.begin(), towlower) appears to fix the problem; but I'd like to know what's going wrong.
My best guess is that perhaps the problem has something to do with changing the case of unicode characters -- perhaps the encoding size of the downcased character is different from the encoding size of the source character?
Does anyone have any ideas what might be going on here? It might help if I knew what "is_singular()" means in the context of boost, but after doing a few google searches I wasn't able to find any documentation for it.
Relevant software versions: Boost 1.40.0; MS Visual Studio 2008.
After further debugging, I figured out what was going on.
The cause of my trouble was that one project in the solution was not defining NDEBUG (despite being in release mode), while all the other modules were. Boost allocates some extra fields in its data structures, which it uses to store debug information (such as whether a data structure has been initialized). If module A has debugging turned off, then it will create data structures that don't contain those fields. Then when module B, which has debugging turned on, gets its hands on that data structure, it will try to check those fields (which were not allocated), resulting in random memory errors.
Defining NDEBUG in all projects in the solution fixed the problem.
An iterator range should only be singular if it's been constructed with the default constructor (stores singular iterators, i.e doesn't represent a range). As it's rather hard to believe that the boost's to_lower function manages to create a singular range, it suggests that the problem might also be elsewhere (a result of some undefined behavior, such as using uninitialized variables which might be initialized to some known value in debug builds).
Read more on Heisenbugs.
So, I have a vector
std::vector<std::string> lines.
I fill this vector up, and can access it like
std::string temp = lines[0];
However, in the immediate window, both
lines[0] - error:overloaded operator not found
and
lines.at(0) - error:symbol is ambiguous
don't work at all. Is there a trick to using the immediate window with c++. I'm mostly coming from a C# background, where everything works nicely (and I have intellisense in the Immediate Window). I wasn't expecting C++ to be great, but I figured it would work for things besides ints. Can anyone tell me what I'm doing wrong? Thanks.
EDIT: I should be clear, nothing really works in the immediate window, this is just a simplified example
EDIT: I'm in debug mode
The immediate and watch windows don't support overloaded operators. There is some support in there for printing standard containers as a whole in a sensible fashion (see, e.g., http://www.virtualdub.org/blog/pivot/entry.php?id=120), but this doesn't extend to being able to use operator[] on them.
Hopefully this will be improved in later revisions of the debugger, but for now, to look at the i'th element of a vector, try lines._Myfirst[i].
(_Myfirst, in the standard libraries that come with VC++, happens to be the member variable in a std::vector that points to the first element of the sequence. So this is just examining a vector as if it were any other object. To work this out, I had to look at the headers... not very convenient, but hopefully this will help you. You can probably do something similar with the other containers, but you'll have to look in the headers to work out how.)
(By the way, if you've been working in C#, the C++ debugger will probably seem by comparison a bit less slick in general, and this is just one example of that. I get the impression there's been much more work put into the CLR side.)
In nowaday's Visual Studio versions (e.g. 2013/2015) _Myfirst member variable does no longer exist for a std::vector variable. Use _C_begin instead - means for the given example use e.g. lines._C_begin[i].
I have a couple of functions in a namespace called stub.
I have to determine the exact start address of the namespace and the end address, of at least the size of the namespace in memory (to copy these functions into another process).
While this worked perfectly in Visual C++ 2008 by adding a
void stub_end() { }
at the end of the namespace and using
size_t size = reinterpret_cast<ULONG_PTR>(stub_end) - reinterpret_cast<ULONG_PTR>(stub_start);
to determine the size of the stub.
This worked because Visual C++ preserved the function order as it is in the .cpp file, however that does not seem to be the case in Visual C++ 2010 anymore.
How can I find out the size of the functions or the whole namespace/stub by using pragma directives, compiler/linker facilities or similar?
With the new push in security these days (heap randomization, layout randomization, etc..) I think this is going to be much more difficult. You may end up having to just copy each function individually.
You can try and place each function in a different section, using the VC++ equivalent GCC's attribute ((section ("name"))) http://www.delorie.com/gnu/docs/gcc/gcc_62.html and then use your technique, or you could place each function in a different source file.
The C++ language provides no guarantees for finding addresses or sizes of namespaces. That said, venture into assembly language and linker instructions.
Many assembly languages have an opcode or mnemonic for placing code at specific addresses. This allows a label to be set up to indicate the start of a memory area. Some linkers have variables for obtaining segment starting addresses and sizes. These would be user defined logical addresses.
In summary, use your assembly and linker tools to define public symbols for the namespace start and length or optionally the end of the segment. In your C++ program, access these labels as extern.