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.
\,,/[>.<]\,,/
Related
THE ANSWER ACCEPTED GAVE ME THE CORRECT EXPLANATION OF THE PROBLEM. I ALSO EDITED THE QUESTION PUTTING THE ANSWER POINT BY POINT IN CAPITAL LETTERS TO MAKE IT CLEARER
I have a c++ code in MacOSX, that use a bit of CoreFoundation.
I use the following function CFPropertyListCreateWithData in my code that takes a CFErrorRef *error as one of its parameters. Well, I create CFErrorRef myError and pass it as &myError
First problem: I think there is a bug in the Documentation, because it gives me some good data as result, but the error is NOT NULL. If I have an error, the data should be NULL, shouldn't it? Or did I misunderstand the documentation?
FIRST SOLUTION: THE ERROR IS UNDEFINED IF THERE IS NO ERROR, SO I HAD TO CHECK THE ERROR ONLY IF THE DATA WERE NULL. MOREOVER I WAS RELEASING USING CFRelease A UNDEFINED OBJECT, THE ERROR, THAT CAUSED MY PROGRAM TO CRASH WITH A SEGMENTATION FAULT
Second problem: I want to check which is the error.
Well I get into this function CFErrorCopyFailureReason, doc here,
but it takes a CFError and not a CFErrorRef, and gives me a CFString. Then, how can I transform my CFErrorRef to CFError?
SECOND SOLUTION: NOSENSE QUESTION, I WAS READING THE DOCUMENTATION OF SWIFT AND NOT OF OBJECTIVE-C
Third problem: the function CFErrorCopyFailureReason gives me a CFString, but I do not know where the CFString is defined! it is not in CoreFoundation/CoreFoundation.h and neither in CoreFoundation/CFString.h, and I have a undefined type error when I try to compile.
Then: In which file is CFString defined? Can I convert it to CFStringRef, and how can I do it?
THIRD SOLUTION: NOSENSE QUESTION, I WAS READING DOCUMENTATION OF SWIFT AND NOT OF OBJECTIVE-C
Fourth problem: with the code I have, if I use CFStringRef and CFErrorRef instead of CFString and CFError, it compiles, but then I have a NSInvalidArgumentException. Shouldn't I have an error at compilation time? I would not like a RunTimeException...
FOURTH SOLUTION: AS THE ANSWER MADE ME UNDERSTAND, I HAD TO CHECK THE ERROR ONLY IF THE DATA WAS NULL. IN THAT CASE I WAS CHECKING A ERROR WITH UNDEFINED DATA THAT GAVE ME THE INVALID ARGUMENT EXCEPTION. OBVIOUSLY, SINCE THE PROBLEM WAS UNDEFINED VALUE IN THE ERROR, THIS IS A RUNTIME EXCEPTION
Well, to conclude, I just want to read and write a Info.plist file in my c++ application. I take inspiration from this, Saving and Restoring Property Lists, sample code and modified it quite a bit. If you have a working sample how to read and modify a Info.plist file, please tell me :) but without using PlistBuddy or other tools please, only c++ API.
TO CONCLUDE: THE SAMPLE CODE WORKS WELL, I JUST MISUNDERSTOOD THE DOCUMENTATION
Thanks to everybody
I think you are misunderstanding the documentation for CFPropertyListCreateWithData(): if it succeeds, the return value is non-NULL, and what error points to is not defined. Don't worry about error unless CFPropertyListCreateWithData() returns NULL.
CFErrorCopyFailureReason() does take a CFErrorRef and return a CFStringRef. You might be looking at the Swift documentation for it, change the language to Objective-C on the top of the documentation page.
Which call is throwing the exception, CFPropertyListCreateWithData()?
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() ) );
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.
So I've got a pretty basic class that has a few methods and some class variables. Everythings working great up until I add a vector to the member variables in the header file:
std::vector <std::string> vectorofstuff;
If all I do is add this line then my program run perfectly but at the end, after all the output is there, I get a message about a seg fault.
My first guess is that I need to call the destructor on the vector, but that didn't seem to work. Plus my understanding is I don't need to call the destructor unless I use the word 'new'.
Any pushes in the right direction? Thanks bunches!
I guess the following either happened to you, or it was something similar involving unrealised dependencies/headers. Either way, I hope this answer might show up on Google and help some later, extremely confused programmer figure out why they're suddenly observing arbitrary crashes.
So, from experience, this can happen if you compile a new version of SomeObject.o but accidentally have another object file #include an old version of SomeObject.hpp. This leads to corruption, which'll be caused by the compiler referring to outdated member offsets, etc. Sometimes this mostly works and only produces segfaults when destructing objects - either related or seemingly distant ones - and other times the program segfaults right away or somewhere in-between; I've seen several permutations (regrettably!).
For anyone wondering why this can happen, maybe this is just a reflection of how little sleep I get while programming, but I've encountered this pattern in the context of Git submodules, e.g.:
MyRepo
/ GuiSubmodule
/ HelperSubmodule
/ / GuiSubmodule
If (A) you have a new commit in GuiSubmodule, which has not yet been pulled into HelperSubmodule's copy, (B) your makefile compiles MyRepo/uiSubmodule/SomeObject.o, and (C) another translation unit - either in a submodule or in the main repo via the perils of #include - links against an older version of SomeObject.hpp that has a different class layout... You're in for a fun time, and a lot of chasing red herrings until you finally realise the simple mistake.
Since I had cobbled together my build process from scratch, I might've just not been using Git/make properly - or strictly enough (forgetting to push/pull all submodules). Probably the latter! I see fewer odd bugs nowadays at least :)
You are probably corrupting the memory of the vectorofstuff member somewhere within your class. When the class destructor is called the destructor of the vector is called as well, which would try to point and/or delete to invalid memory.
I was fooling around with it and decided to, just to be sure, do an rm on everything and recompile. And guess what? That fixed it. I have no idea why, in the makefile I do this anyway, but whatever, I'm just glad I can move on and continue working on it. Thanks so much for all the help!
Hoping some of you TinyXML++ people can help me out. Really, since you recomended to me before I think you owe me ;)
I have the following code:
//ticpp::Iterator< ticpp::Element > child( "SetPiece" );
ticpp::Iterator< ticpp::Node > child("SetPiece");
GLuint lc_SPieces = 0;
for(child = child.begin( this ); child != child.end(); child++ )
{
lc_SPieces++;
}
If I use the top declaration for child I get the error:
Unhandled exception at 0x7c812aeb in
Drawing.exe: Microsoft C++ exception:
__non_rtti_object # 0x0012f7b4.
And I get it in dbgheap.c at this line:
pvBlk = _heap_alloc_dbg(nSize, nBlockUse, szFileName, nLine);
What's weird is it works with Node, and I know that there are elements in there(I checked using the TinyXML iteration methods).
Has anyone run into this before?
just poking in the dark, i don't know tinyxml, but it seems that a dynamic_cast went wrong.
If you dynamic_cast<> a pointer, you get a NULL-pointer on failure. However, if you cast to a reference type, there is no concept of a NULL-reference, so the runtime throws this exception (or bad_type). MSDN on dynamic_cast, and why it can go wrong
The line you pasted for the exception to occur does not help to clear up the situation, since it identifies the symptom rather than the cause.
Try to identify the cast that went wrong, you should be able to find it if you walk up the stack and find the last method in tinyxml libs or headers. Then you can decide whether tinyxml is worng, or you just applied it the wrong way.
good luck!
__non_rtti_object is generated by the dynamic_cast operator if the passed pointer or reference does not point to a polymorphic object, but to some garbage instead. Maybe the object had been deleted earlier.
Step through the code in the debugger and check where the dynamic_cast is used and what is passed to it.
hth
Paavo
Project -> Properties -> C/C++ -> Language -> Enable Run-Time Type Info