I am trying to debugg the project on MSVS 2010.
Implementation - c++; when i am degubbing the source code, i get the following failure reported by MSVS.
Failure reported:
"First chance exception at 0x00000013fb5b9ee in unit.exe: 0xc00000005 access voilation reading location 0x00000000000000c."
the problem lies in obtaining address.
int base = (*(abc::g_runc1.m_paulsenderpin.m_lastchunk_p)).xcpp::cxcppoutput::m_baseaddress;
my project is very big to include the source code,
In short it can be described as:
- paul is a module with sender pin connected to c1.
- xcpp is the interface
this source code and the project is correct and works without failure on ARM compiler, but on MSVS it gives access violation error.
On msdn there are some posts about permission set by assembly, and which avoids to read the addressed location. if so, how to change it... ?
or is there any better option to find the problem...?
Any help is appreciated.
Your code is trying to access location that actually isn't owned by it's process. No data of user applications can be located at addresses so close to zero. As your expressions is too long to simply find where is the member containing zero reference, my tip is m_last chunk_p, and the m_baseaddress seems to be member at offset 12.
There is one simple explanation why does your code work fine when it's compiled by something that works with ARM: ARM uses aligned memory access, so class and structure members are aligned to full blocks, although they don't always use whole space allocated for them. Therefore you use bigger pointer or wrong memset parameters somewhere in your code and your pointer gets overwritten.
Problem may also disappear when you compile it with another version of (possibly another) compiler (or non machine with different processor architecture 32/64), as the size of fundamental types isn't always the same.
You should try to check what pointed is actually zero (or possibly 12) in your expression and try to set a watch on it. Be sure you use sizeof properly everywhere.
The Problem lies with the memory addressing, in ARM debugger 32 bits and MSVS10 48 bits of addressing, because of it the MSB byte is lost and so cannot find the correct memory address...!!!
Related
I've converted some legacy Fortran code to C using the f2c converter (f2c), and I've created a Visual Studio 10 solution on Windows 7 (64-bit). I've also had to link my C++ program (test.cpp, containing my main function) with the f2c library (built on my system using nmake).
The program runs, but once the end of the main function is reached, I receive the following Debug error:
Stack around the variable 'qq' was corrupted
Stack around the variable 'pf' was corrupted
Stack around the variable 'ampls' was corrupted
I am wondering if this might be due to a "correction" made by the f2c converter in the converted C (from Fortran) file:
/* Parameter adjustments */
--x1;
--xabs;
--ximag;
--xreal;
--work4;
--work3;
--work2;
--work1;
--ampls;
--pf;
--qq;
--tri;
This seems a bit odd, since all of these variables are C arrays, and I think that the f2c program is simply doing some pointer arithmetic so that index 0 in the array becomes index 1, in a similar fashion to Fortran.
I don't know if this could also be due to something going wrong with the converted code accessing an element of the array that has not been allocated.
What is the best way to debug this error and fix it?
Potential reasons:
This error is usually related to writing outside the bounds of an array (dynamic or static array). This error can occur by writing\getting a value in a -ve index or index >= size_of_array.
This error also accurs if your pointer is not set to its correct location. (e.g. ptr = 0, ptr = 55, points to deleted (released; or has been free) memory, or any invalid address)
Best way to debug your error in my mind is to debug your prorgam step-by-step and watch those pointer values. There must be some wrong with them.
What you say could be true. I would suggest to create a very small program that uses an array and decrements the pointer exactly as f2c does. Something like
int aa[10];
int *pa = aa;
--pa;
pa[1] = ...
That is, test the suspected code in the small scale. You might isolate the cause to the problem this way. (Finding a workaround is a different story)
Are you compiling with the debug versions of the crt? That might give you some more information.
Also, is it possible that your library is built as C and your application is written as C++?
Those errors you mention are sometimes because of different calling conventions. You do state it's a 64bit application, so it shouldn't be an issue (all 64bit apps use the same calling convention), but it's worth looking into.
Is it possible to add all the fortran converted code to visual studio and not do a seperate make?
I'm compiling a program on remote linux server. The program compiled. However when I run it the program ends abruptly. So I debugged the program using DDT. It spits out the following error:
Process 0:
Memory error detected in ClassName::function (filename.cpp:6462).
Thread 1 attempted to dereference a null pointer or execute an SSE instruction with an
incorrectly aligned memory address (the latter may sometimes occur spuriously if guard
pages are enabled)
Tip: Use the stack list and the local variables to explore your program's current
state and identify the source of the error.
Can anyone please tell me what exactly this error means?
The line where the program stops looks like this:
SumUtility = ParaEst[0] + hhincome * ParaEst[71] + IsBlack * ParaEst[61] + IsBachAss * (ParaEst[55]);
This is within a switch case.
These are the variable types
vector<double> ParaEst;
double hhincome;
int IsBlack, Is BachAss;
Thanks for the help!
It means that:
ParaEst is NULL or a bad Pointer
ParaEst's individual array values are not aligned to 16-byte boundaries, required for SSE.
hhincome, IsBlack, or IsBachAss are not aligned to 16-byte boundaries and are SSE type values.
SumUtility is not aligned to 16-bytes and is a SSE type field.
If you could post the assembly code of the exact line that failed along with the register values of that assembler line, we could tell you exactly which of the above conditions have failed. It would also help to see the types of each variable shown to help narrow root the cause.
Ok... The problem finally got fixed.
The issue was that the expression where the code was breaking down was in a newly defined function. However for some weird reason running the make-file did not incorporate these changes and was still compiling using the previously compiled .o file. This resulted in garbage values being assigned to the variables within this new function. To top things off the program calls this function as a first step. Hence there was this systematic breakdown. The technical aspect of this was what Michael alluded to.
After this I would always recommend to use a make clean option in the make file. The issue of why running the make file is failing to compile the modified source file is an issue that definitely warrants further discussion.
Thanks for the responses!!
I'm using someone else's C++ app as a guide for my own C# application and I've come across a strange pattern:
array[index].property;
No assignment. Nothing evaluated.
I assume this is a vestigial line, left over from when an assignment would have been done here.
But I'm not sure. And seeing as I'm having problems, I'm starting to turn over even the most unlikely rocks.
My question then: does that line do anything? Does it perhaps perform a function akin to touch?
Update - real code
The real code is:
devconfig[fbbloop-1].wAlphaMax;
Where devconfig is an array of the following struct:
typedef struct tagBIRDDEVICECONFIG
{
BYTE byStatus; // device status (see bird device status bits, above)
BYTE byID; // device ID code (see bird device ID's, above)
WORD wSoftwareRev; // software revision of device
BYTE byError; // error code flagged by device
BYTE bySetup; // setup information (see bird device setup bits, above)
BYTE byDataFormat; // data format (see bird data formats, above)
BYTE byReportRate; // rate of data reporting, in units of frames
WORD wScaling; // full scale measurement, in inches
BYTE byHemisphere; // hemisphere of operation (see bird hemisphere codes, above)
BYTE byDeviceNum; // bird number
BYTE byXmtrType; // transmitter type (see bird transmitter type bits, above)
WORD wAlphaMin[7]; // filter constants (see Birdnet3 Protocol pp.26-27 for values)
WORD wAlphaMax[7]; // filter constants (see Birdnet3 Protocol pp.26-27 for values)
WORD wVM[7]; // filter constants (see Birdnet3 Protocol pp.26-27 for values)
BIRDANGLES anglesReferenceFrame; // reference frame of bird readings
BIRDANGLES anglesAngleAlign; // alignment of bird readings
}
BIRDDEVICECONFIG;
The code you included fits a pattern that I call "This programmer is a goof rocket". The code either does nothing or there is a side effect on which the programmer is depending. In both cases, "This programmer is a goof rocket" is a good description of a programmer who codes like that.
The case of "oh, the previous coder just make a mistake" is mearly a nice variant of "This programmer is goof rocket".
The original developer most likely ran into a bug with the compiler not recompiling some changed files.
This happens fairly often with Visual Studio, less often with more recent versions, when you change some central code and use minimal rebuilds.
Essentially, the compiler will not notice some change and link with old or incorrect object code. The result is some strange behavior that doesn't make sense and is nearly impossible to debug, i.e. a function returning to the wrong address or jumping into the middle of some other function for no apparent reason.
The solution to this is to do a full rebuild, but if the developer doesn't immediately know that this is a mistake on the compiler's side, they might think that the issue is in the code and try to fix it.
Often, introducing a code change that has no actual effect on the functionality of the code will fix the issue. It's also fairly common to see a line that's just 0; used to achieve the same effect. Again, if the developer doesn't know that the issue was caused by the compiler, they might think that this line of code that does nothing is important.
It doesn't do much if the container is indeed an array and index is within array bounds. If the container is is a map, a record will be created for index key.
No, unless the operator [] was overloaded. Even so, it is a weird thing to do. Probably it is a leftover from something else.
No, there's no function to that line. It's a primitive access, so no funky overloading shenanigans going on here. It could be covering up for some compiler bug or error, and it wouldn't be the first time I've seen nonsense lines have to be left in for that reason, but it certainly doesn't serve an actual purpose in the execution of the program.
From your update it looks like the code is just accessing the address of the first item of an array. You can safely remove the line.
Often when you see nonsensical code like that, it was created because programmer wanted to supress some pedantic warning from either the compiler or some static analysis tool.
If you have access to the versioning system, you could maybe go back in time and see during which conditions when it was created...
We are on HPUX and my code is in C++.
We are getting
BUS_ADRALN - Invalid address alignment
in our executable on a function call. What does this error means?
Same function is working many times then suddenly its giving core dump.
in GDB when I try to print the object values it says not in context.
Any clue where to check?
You are having a data alignment problem. This is likely caused by trying to read or write through a bad pointer of some kind.
A data alignment problem is when the address a pointer is pointing at isn't 'aligned' properly. For example, some architectures (the old Cray 2 for example) require that any attempt to read anything other than a single character from memory only occur through a pointer in which the last 3 bits of the pointer's value are 0. If any of the last 3 bits are 1, the hardware will generate an alignment fault which will result in the kind of problem you're seeing.
Most architectures are not nearly so strict, and frequently the required alignment depends on the exact type being accessed. For example, a 32 bit integer might require only the last 2 bits of the pointer to be 0, but a 64 bit float might require the last 3 bits to be 0.
Alignment problems are usually caused by the same kinds of problems that would cause a SEGFAULT or segmentation fault. Usually a pointer that isn't initialized. But it could be caused by a bad memory allocator that isn't returning pointers with the proper alignment, or by the result of pointer arithmetic on the pointer when it isn't of the correct type.
The system implementation of malloc and/or operator new are almost certainly correct or your program would be crashing way before it currently does. So I think the bad memory allocator is the least likely tree to go barking up. I would check first for an uninitialized pointer and then bad pointer arithmetic.
As a side note, the x86 and x86_64 architectures don't have any alignment requirements. But, because of how cache lines work, and for various other reasons, it's often a good idea for performance to align your data on a boundary that's as big as the datatype being stored (i.e. a 4 byte boundary for a 32 bit int).
Most processors (not x86 and friends.. the blacksheep of the family lol) require accesses to certain elements to be aligned on multiples of bytes. I.e. if you read an integer from address 0x04 that is okay, but if you try to do the same from 0x03 you will cause an interrupt to be thrown.
This is because it's easier to implement the load/store hardware if it's always on a multiple of the data size with which you're working.
Since HP-UX runs only on RISC processors, which typically have such constraints, you should see here -> http://en.wikipedia.org/wiki/Data_structure_alignment#RISC.
Actually HP-UX has its own great forum on ITRC and some HP staff members are very helpful. I just took a look at the same topic you are asking and here are some results. For example the similar problem was caused actually by a bad input parameter. I strongly advise you first to read answers to similar question and if necessary to post your question there.
By the way it is likely that you will be asked to post results of these gdb commands:
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4
Most of these issues are caused by multiple upstream dependencies linking to different versions of the same library.
For example, both the gnustl and stlport provide distinct implementations of the C++ standard library. If you compile and link against gnustl, while one of your dependencies was compiled and linked against stlport, then you will each have a different implementation of standard functions and classes. When your program is launched, the dynamic linker will attempt to resolve all of the exported symbols, and will discover known symbols at incorrect offsets, resulting in the BUS_ADRALN signal.
Im trying to get the engine version of a game from a global pointer, but I am fairly new to this. Here is a very small example I found...
http://ampaste.net/mb42243
And this is the disassembly for what I am trying to get, the pointer (gpszVersionString) is the highlighted line (line 5)
http://ampaste.net/m2a8f8887
So what I need to find out is basically using the example approach I found to get it, would I need to basically sig out the first part of the function and find the offset to that line?
Like...
Memory signature - /x56/x8B/x35/x74/xD5/x29/x10/x68/x00/xA8/x38/x10
Then an offset to reach that line? (not sure how to find the offset)
You can't directly do this. Process address space is completely unique to your process -- 0xDEADBEEF can point to "Dog" in one process, while 0xDEADBEEF can point to "Cat" in another. You would have to make operating system calls that allow you to access another process' address space, and even then you'd have to guess. Many times that location will be different each run of the application -- you can't generally predict what the runtime layout of a process will be in all cases.
Assuming you're on Windows you'll need to (EDIT: You don't need A and B in all cases but you usually need them) A. be an administrator, B. take the SeDebugPrivilege for your process, C, open a handle to the process, and then D. use ReadProcessMemory/WriteProcessMemory to do what you want.
Hope that helps :)
EDIT 2: It looks like you're looking at an address taken from a disassembler. If that's the case, then you can't use that value of the address -- the image can be re-based at runtime and the value there would be completely different. Particularly on recent versions of Windows which support Address Space Layout Randomization.