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.
Related
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
In a recent program I've made I had some worrying random crashes/ crash on shutdown, after stripping down I think I've narrowed it down to a SIGTRAP which happens when a vector is created under specific circumstances. The main bulk of the code can be found here :http://pastebin.com/xp9Cm04Q and the tile class here : http://pastebin.com/Niv7SSyF (the issue arises when the buildworld subroutine is ran) and the console output can be found here http://pastebin.com/7HyaMke8 . The debugger goes to new_allicator when this happens, if that's worth knowing.
Also note that for some reason removing the calls to rTest in the tiles (which only makes a call to the RNG that class has), but only if another subZone has been created since then. Needless to say I am completely baffled as to why this is happening.
Am I doing anything dumb here? I'm only using std libraries, so I don't think I could of installed them wrong or anything. Is this an issue I can/should ignore? Any kind of help on how to approach this issue is greatly appreciated.
tiles.back().back().giveRGen(&zoneRGen);
One problem: your tile have a link to RNG object; that link would be broken then subZone copied. For example here:
allZones.push_back( subZone( x , y , worldRGen() ) );
I'm using FMOD in my c++ project. There are no errors or warning when building, however when debugging; I get the following runtime error from the FMOD_System_CreateSound function:
Unhandled exception at 0x008e3f56 in Audio_Demo.exe: 0xC0000005: Access violation reading location 0xfdfdfdfd.
Here is the function call:
FMOD_System_CreateSound(system, filename.c_str(), FMOD_DEFAULT, NULL, &sample->sample);
Where, system is a pointer to an FMOD_SYSTEM object, sample is a helper class and sample->sample is a pointer to an FMOD_SOUND object.
If it's any help; in the project I have each of the arguments on a separate line and the error seems to occur at the final argument (sample->sample).
Thanks in advance for any help.
\,,/[>.<]\,,/
Spent the whole day scratching my head about this and only just decided to post on here for help. As luck would have, a bit more digging around and I realised my mistake.
I hadn't properly initialised my helper class containing the FMOD_SOUND object pointer, so it was null and thus threw an error. Just switching around a couple of lines of code in my initialiser function sorted this (i.e. my helper class was intialised before FMOD_System_CreateSound was called)
Figured I'd post the solution I found as I can't stand it when a poster asks a question; figures it out and says "Ah, it's alright. I solved it!" without sharing the answer with the rest of the world.
Hopefully, this will help someone having a similar problem. If not, then please comment and I'll try to clarify further.
\,,/[>.<]\,,/
so I am working in VS 2008 with C++ for an embedded environment(ARM processor). I've built a medium sized project for my company. It has thus far been a windows application. I was asked to change it to a console application because that makes more sense for this application. I had no real reason for making it a windows application... At first, I just changed the appropriate settings (I think) in VS and then rebuilt. It built fine, but then I got the exception quoted in the title each time I tried to run the program. I want to emphasize that the program was working perfectly before I switched it to a console application. I did do a full clean and rebuild of the entire solution as well.
I thought that this was probably just a problem with me manually changing the settings, so I made a new project that was set to be a console app and plugged all of the source/other associated projects into that. This builds fine as well once I got all of the different projects in the solution linked together correctly, but the same error comes up.
When the program crashes, it stops at the insert command in the following method:
template<class Elem>
Node<Elem>* Node<Elem>::addChild(const Elem& value)
{
Node<Elem>* newNode = new Node(value);
newNode->m_pParentNode = this;
m_childList.push_back(newNode);
m_sNodeSet.insert(newNode);
return newNode;
}
The m_sNodeSet is there to enforce the rule that each node in the tree must be unique. The error occurs the first time that this addChild method is called. At this time, the m_sNodeSet is of size zero and needs to allocate some memory. But the exception thrown is Access Violation, not Bad Alloc as might be expected. I did try adding a m_sNodeSet.get_allocator().allocate(5) before the insert statement to see if that would do anything, but the same exception is thrown. The m_sNodeSet is a static member variable, if that makes a difference.
This Node class is a custom tree object I have created. I have not changed anything in this tree project for weeks and it has been working fine. I don't think that I am throwing anything at this tree project that it hasn't seen before and performed perfectly with, so I don't think the problem lies with the tree project itself.
I am certain that this is not an issue of accessing STL containers across library boundaries either. This error is occurring within the operations of a single static library.
I feel like there must be some setting that still needs to be changed in my solution to make this work properly. There are several projects in the solution, one DLL, one LIB, and one EXE. The tree is a fourth project, but that one is simply put into the appropriate projects' "additional includes." I only changed the EXE so that it would execute as a console app.
If you all have any inklings on what could be the problem here it would be much appreciated.
If you have declared:
// Global scope
// > (quote)The m_sNodeSet is a static member variable,
std::set<Node<Elem>*> Node<Elem>::m_sNodeSet;
Personal note: the prefix m_ usually is a donator of a member variable (not a static member). Thus you are going to confuse a lot of people using this prefix.
If m_sNodeSet is a static member and the above code is being run before main then you potentially have a problem with initialization order. This is trivial to resolve (see below). Otherwise you have some memory corruption.
class Node
{
// Remove this line
// static std::set<Node*> m_sNodeSet;
// Replace with this code
static std::set<Node*>& getNodeSet()
{
static std::set<Node*> sNodeSet;
return sNodeSet;
}
// Replace all references to m_sNodeSet with getNodeSet()
}
This works because inside the method getNodeSet() the variable sNodeSet is static and thus created on first use and remains alive for the length of the program. Each call will return a reference to the same object. Because it is created on first call it is guaranteed to be alive (and fully constructed) when returned to the usage point.
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.