I am working on a C++-fortran mix compiling project. On the fortran side, I wrote an interface to segregate the C++ reference/pointers to fortran variables. After the fortran subroutine did their work, the interface will assign the value one-by-one to the C++ array. The problem occurred when it went back to C++ side. I can see the value of each array elements in the C++ debugger, but when I use std::cout<<arr[0]<<std::endl, it gives me the access error:
Exception thrown at 0x79762B8E (msvcp140d.dll) in TEST_IO.exe: 0xC0000005: Access violation reading location 0x9C6D0014
I wrote a simplified test code as:
#include <iostream>
extern "C" {void fort_interface(<typeName1> &par1,<typename2> *par2,....,<typeName> *output);}
int main()
{
..... //setup input parameters
float *arr = new float[N_arr]; //N_arr is big enough.
float check = 12321;
std::cout<<check<<std::endl;
/*the float variable check is independent from fort_interface, just to check the memory status*/
fort_interface(par1, par2,...,arr);
std::cout<<check<<std::endl;//exception occurs!
}
The same exception reported even I print out "check" that did no business with fort_interface(). At the same time, the value of "check" was 12321 in the debugger.
I wrote another toy fortran-C++ code to test how fortran play with pointers/references, everything goes well. Value can be printed, destructor works well too.
Sorry that I cannot upload the fortran-C++ interface here because it contains 100+ parameters (that's the reason why I wrote this interface to keep fortran original code intact with outside argument.) I just want to know why I can see the value in debugger but it cannot be accessed? Thank you for your help!
Update: The problem was solved! I passed a pointer to pointer to the fortran subroutine, which leaded the segment error. Nothing wrong about fortran-C mix compile setting. Just because of the segment error. Thank you all again!
Since I can't see your Fortran-C++ interface, I will make a guess that might help.
When you process arrays in fortran, they are saved as columns in your memory, while C/C++ saves them as rows. which makes the interface between these two languages tricky.
For example, if you have arr[5][5] and you call the element arr[1][0] in C, the compiler will fetch the row 1 and keep it in your cache, while fortran compiler will fetch column 0 and keep it in your cache.
I hope this helps
Related
I've been asked to use a library provided here and I was following the instructions to build it in Windows, those are located here.
Now I downloaded Intel Parallel Studio XE as requested and did everything as in the instructions but there's a problem inside the code that I can't figure out completely how to solve it. The compiler says Error #6362: The data type(s) of the argument(s) are invalid..
The lines that give trouble are both the same: call free(adr(n))
And the declaration of adr(n) is what I don't know if it is correct or not since I haven't touched FORTRAN 77 in a while. It is: adr(n) = malloc(length*ipa) where ipa and length are properly defined but I don't know if adr(n) is already defined somewhere else in the header files. Should I just add a declaration at the top (I heard FORTRAN needs declarations at the top) or should I do something else? What I know is that adr(n) should be length*ipa bytes but not if it should be a specific type or not, and I don't remember how to do something along the lines of char * adr = (char *) malloc(length*ipa); as I would do in C.
This was asked and answered at https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/801638 The source being used declared the variable as integer*8 (nonstandard), but a 32-bit build was being done. Since the Intel compiler treats malloc and free as intrinsics, it detected the mismatch.
In Fortran when you pass an array to a subroutine you do not include an index. By passing adr(n) you are only passing the nth element of adr to the subroutine. You most likely want to pass the whole array like this:
call free(adr)
If this does not do it, please post a Minimal, Complete, and Verifiable example.
Welcome to stackoverflow. I suggest you take the tour. and learn how to ask good questions.
I'm noticing that whenever I am declaring or initializing int c = 0, I seem to get a segmentation fault. It is only when I comment out that particular line of my code that it works fine. Here is a portion of my code:
int a = 0;
int b = 0;
int c = 0;
struct alphabet{
int first;
char word[30];
};
I've tested my code with just a and b as my only integers. It only began giving me that the segmentation fault once I tried initializing c later on. I just don't understand why this would even happen. Can someone help me?
Thank you in advance!
Since you have posted a very short peace of code, it is hard to give you a concrete advise. Hovewer, let's try as for the 'average' case. All your three int variables are located at the stack frame. Thus, adding more variables like c you may move the location of the rest stack variables which may be defined later. In particular, if you instantiate an instance of your structure alphabet which has an array field word. Imagine what happens if you underrun it (out of baundary access to the left baundary of the array). In the case if this underrun overlaps the area where c is located and you write to it by initializing c, then potentially string operation on word may crash. So, my advise would be do a code review starting down from the this function. Focus is on using uninitialized variables, out of boundary access and hanging pointers in respect to stack variables. A good practice would also be to use some static code analysis tool. For more concrete hints you need to extend your question to give more details as is recommended in the comments above.
So i have one of the wierdest bug i've seen in my life.
I've bought a DirectX 11 book which comes with some [sample code]:http://www.d3dcoder.net/d3d11.htm
I am pretty sure at some point in time i managed to compile and run every single sample app, but now, i have a "Access violation writing location 0xCCCCCCCC" error at runtime.
Now, this is happening one the following line :
ShadowsApp::ShadowsApp(HINSTANCE hInstance) : D3DApp(hInstance)
{
mMainWndCaption = L"Shadows Demo"; <- Crashes here !!!
mLastMousePos.x = 0;
mLastMousePos.y = 0;
...
}
mMainWndCaption being declared like this in the .h
std::wstring mMainWndCaption;
and set with a default value in the constructor of the class ShadowsApp inherits from
D3DApp::D3DApp(HINSTANCE hInstance) :
mhAppInst(hInstance),
mMainWndCaption(L"D3D11 Application"),...
I think, this is already quite odd ...
Now the strangest part comes when i declare ANY variable of ANY type in the d3dApp.h, I no longer have the "Access violation writing location 0xCCCCCCCC" error, everything builds and run perfectly.
As a C# programmer, this makes absolutely no sense to me. How can the declaration of a random variable in a class can "fix" such a thing ?!
Any suggestion would be greatly appreciated :-)
This page has a good description and background of the various "magic values" you might encounter when dealing with stack and heap.
From the page:
If you are seeing the 0xcccccccc bit pattern it means that you are reading memory that is on the current thread stack that has not been initialised.
Given the code snippet you've posted so far, and what you've described about "fixing" it with another variable declared in the base class, it sounds like the base and derived objects might not be in agreement as to their memory layout. Are they in the same library or executable? Check your compilation flags and make sure they match.
One strategy is to reduce your problem down to the minimal set of steps to reproduce the problem. You can make a copy of your project and start removing fields and methods until it works, and see if that helps you isolate it further.
"Access violation writing location 0xCCCCCCCC" error at runtime.
You're trying to use unitialized pointer under msvc in debug build.
Initialize pointer.
mMainWndCaption = L"Shadows Demo"; <- Crashes here !!!
Install breakpoint at this location, run application under debugger, and investigate contents of variables (within "watch" window, or by hovering mouse over individual variables), including this pointers.
0x004069f1 in Space::setPosition (this=0x77733cee, x=-65, y=-49) at space.h:44
0x00402679 in Checkers::make_move (this=0x28cbb8, move=...) at checkers.cc:351
0x00403fd2 in main_savitch_14::game::make_computer_move (this=0x28cbb8) at game.cc:153
0x00403b70 in main_savitch_14::game::play (this=0x28cbb8) at game.cc:33
0x004015fb in _fu0___ZSt4cout () at checkers.cc:96
0x004042a7 in main () at main.cc:34
Hello, I am coding a game for a class and I am running into a segfault. The checker pieces are held in a two dimensional array, so the offending bit appears to be invalid x/y for the array. The moves are passed as strings, which are converted to integers, thus for the x and y were somehow ASCII NULL. I noticed that in the function call make_move it says move=...
Why does it say move=...? Also, any other quick tips of solving a segfault? I am kind of new to GDB.
Basically, the backtrace is trace of the calls that lead to the crash. In this case:
game::play called game::make_computer_move which called Checkers::make_move which called Space::setPosition which crashed in line 44 in file space.h.
Taking a look at this backtrace, it looks like you passed -65 and -49 to Space::setPosition, which if they happen to be invalid coordinates (sure look suspicious to me being negative and all). Then you should look in the calling functions to see why they have the values that they do and correct them.
I would suggest using assert liberally in the code to enforce contracts, pretty much any time you can say "this parameter or variable should only have values which meet certain criteria", then you should assert that it is the case.
A common example is if I have a function which takes a pointer (or more likely smart pointer) which is not allowed to be NULL. I'll have the first line of the function assert(p);. If a NULL pointer is ever passed, I know right away and can investigate.
Finally, run the application in gdb, when it crashes. Type up to inspect the calling stack frame and see what the variables looked like: (you can usually write things like print x in the console). likewise, down will move down the call stack if you need to as well.
As for SEGFAULT, I would recommend runnning the application in valgrind. If you compile with debugging information -g, then it often can tell you the line of code that is causing the error (and can even catch errors that for unfortunate reasons don't crash right away).
I am not allowed to comment, but just wanted to reply for anyone looking more recently on the issue trying to find where the variables become (-65, -49). If you are getting a segfault you can get a core dump. Here is a pretty good source for making sure you can set up gdb to get a core dump. Then you can open your core file with gdb:
gdb -c myCoreFile
Then set a breakpoint on your function call you'd like to step into:
b MyClass::myFunctionCall
Then step through with next or step to maneuver through lines of code:
step
or
next
When you are at a place in your code that you'd like to evaluate a variable you can print it:
p myVariable
or you can print all arguments:
info args
I hope this helps someone else looking to debug!
I have a piece of templated code that is never run, but is compiled. When I remove it, another part of my program breaks.
First off, I'm a bit at a loss as to how to ask this question. So I'm going to try throwing lots of information at the problem.
Ok, so, I went to completely redesign my test project for my experimental core library thingy. I use a lot of template shenanigans in the library. When I removed the "user" code, the tests gave me a memory allocation error. After quite a bit of experimenting, I narrowed it down to this bit of code (out of a couple hundred lines):
void VOODOO(components::switchBoard &board) {
board.addComponent<using_allegro::keyInputs<'w'> >();
}
Fundementally, what's weirding me out is that it appears that the act of compiling this function (and the template function it then uses, and the template functions those then use...), makes this bug not appear. This code is not being run. Similar code (the same, but for different key vals) occurs elsewhere, but is within Boost TDD code.
I realize I certainly haven't given enough information for you to solve it for me; I tried, but it more-or-less spirals into most of the code base. I think I'm most looking for "here's what the problem could be", "here's where to look", etc. There's something that's happening during compile because of this line, but I don't know enough about that step to begin looking.
Sooo, how can a (presumably) compilied, but never actually run, bit of templated code, when removed, cause another part of code to fail?
Error:
Unhandled exceptionat 0x6fe731ea (msvcr90d.dll) in Switchboard.exe:
0xC0000005: Access violation reading location 0xcdcdcdc1.
Callstack:
operator delete(void * pUser Data)
allocator< class name related to key inputs callbacks >::deallocate
vector< same class >::_Insert_n(...)
vector< " " >::insert(...)
vector<" ">::push_back(...)
It looks like maybe the vector isn't valid, because _MyFirst and similar data members are showing values of 0xcdcdcdcd in the debugger. But the vector is a member variable...
Update: The vector isn't valid because it's never made. I'm getting a channel ID value stomp, which is making me treat one type of channel as another.
Update:
Searching through with the debugger again, it appears that my method for giving each "channel" it's own, unique ID isn't giving me a unique ID:
inline static const char channel<template args>::idFunction() {
return reinterpret_cast<char>(&channel<CHANNEL_IDENTIFY>::idFunction);
};
Update2: These two are giving the same:
slaveChannel<switchboard, ALLEGRO_BITMAP*, entityInfo<ALLEGRO_BITMAP*>
slaveChannel<key<c>, char, push<char>
Sooo, having another compiled channel type changing things makes sense, because it shifts around the values of the idFunctions? But why are there two idFunctions with the same value?
you seem to be returning address of the function as a character? that looks weird. char has much smaller bit count than pointer, so it's highly possible you get same values. that could reason why changing code layout fixes/breaks your program
As a general answer (though aaa's comment alludes to this): When something like this affects whether a bug occurs, it's either because (a) you're wrong and it is being run, or (b) the way that the inclusion of that code happens to affect your code, data, and memory layout in the compiled program causes a heisenbug to change from visible to hidden.
The latter generally occurs when something involves undefined behavior. Sometimes a bogus pointer value will cause you to stomp on a bit of your code (which might or might not be important depending on the code layout), or sometimes a bogus write will stomp on a value in your data stack that might or might not be a pointer that's used later, or so forth.
As a simple example, supposing you have a stack that looks like:
float data[10];
int never_used;
int *important pointer;
And then you erroneously write
data[10] = 0;
Then, assuming that stack got allocated in linear order, you'll stomp on never_used, and the bug will be harmless. However, if you remove never_used (or change something so the compiler knows it can remove it for you -- maybe you remove a never-called function call that would use it), then it will stomp on important_pointer instead, and you'll now get a segfault when you dereference it.