Okay, so long weekend away with Macbook I started making an asset loader for 2D game platforms, its working fine in xcode, but when I got home and tried and load it up on Windows I get a debug error.
Essentially what is happening is that the first call to the iterator works? the second doesn't, but only on the second attempt at calling the second one will it cause the error (this is in a game loop). I've swapped the calls but the same result happens.
The program (in debug) quits and gives me the message
AssetLoadingWin.exe has triggered a
breakpoint
then points to the following code in dbgrptt.c
#undef _CrtDbgBreak
/* These methods don't need a separate
wchar version. Hence they need to be compiled only once from
the original file */
_CRTIMP void _cdecl _CrtDbgBreak(
void
)
{
DebugBreak(); // <-- breakpoint here
}
if I let it continue i get the following message
Microsoft Visual Studio C Runtime
Library has detected a fatal error in
AssetLoadingWin.exe.
Press Break to debug the program or
Continue to terminate the program.
which in turn points to the code in dbghook.c
__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
/* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
(_Reserved);
_debugger_hook_dummy = 0;
}
After alot of breakpoints Its been narrowed down to an iterator calling a method.
// line 347 in the pastie.
void libImageDraw(GraphicIt &gfxIt, GraphicOptions &opts) {
gfxIt->second->draw(opts.x, opts.y, opts.z); line
}
Thanks for any pointers.
Full Source Code
window.cpp
asset_manager.hpp
It looks like you don't check the result of the find call on line 239 in the drawGraphic function.
Also i think the loadAll loop looks dodgy. You're looping over m_assetsToLoad and modifying it at the same time in loadResource.
Related
I have a Qt application that I am building with newer versions of VC++ and GDCM. I had built the application previously with VC++ 2015, and old version of GDCM, and it compiled and ran just fine. Now I'm running into an exception in a string assignment.
gdcm::Reader r;
r.SetFileName(f.toStdString().c_str());
if (r.Read()) {
gdcm::StringFilter sf;
sf = gdcm::StringFilter();
sf.SetFile(r.GetFile());
std::string s;
/* get modality */
gdcm::Tag tag = gdcm::Tag(0x0008,0x0060);
s = sf.ToString(tag); // <-- runtime error here...
fileModality = QString(s.c_str());
/* get patientID */
s = sf.ToString(gdcm::Tag(0x0010,0x0020));
filePatientID = QString(s.c_str());
/* get protocol (seriesDesc) */
s = sf.ToString(gdcm::Tag(0x0008,0x103E));
fileProtocol = QString(s.c_str());
}
If I use the assign function, the error moves to the next line, in the conversion from a string to a c_str.
s.assign(sf.ToString(tag));
fileModality = QString(s.data());
I'm not sure what's going on, but it seems to be an issue with GDCM not properly returning a string object.
Edit: The error is a dialog box with the following
The inferior stopped because it triggered an exception.
Stopped in thread 0 by: Exception at 0x7ffaa7b8f621, code: 0xc0000005: read access violation at: 0xfffffffffff, flags=0x0 (first chance).
And the call stack, starting with my own function call
1 std::_Container_base12::_Swap_all xutility 239 0x7ff7764a7b7a
2 std::_String_alloc<std::_String_base_types<char,std::allocator<char>>>::_Swap_all xstring 2029 0x7ff7764a7af7
3 std::string::_Assign_rv_contents_with_alloc_always_equal xstring 2353 0x7ff7764a619d
4 std::string::_Assign_rv_contents xstring 2326 0x7ff7764a6132
5 std::string::operator= xstring 2308 0x7ff7764a37cd
6 MainWindow::GetFileType mainwindow.cpp 477 0x7ff77648784c
... <More>
I'm putting this here in case anyone encounters a similar problem.
I was able to figure out the problem. GDCM was compiled in Release... but my application was compiled in Debug. Somehow it linked just fine and mostly ran, but when it encountered a function call from the GDCM library, it crashed. Compiling everything in Release or Debug fixed it.
I'm writing a cpp app for some while now. A few hours into the day made a small change did a build to test it and to my surprise , the build executed and nothing happened , it didn't stop executing it had a process running.
so I stopped it. and this is what I have tried.
Restrating my PC- Same Result
Making a breakpoint after the entry point. - Same Result
breakpoint didn't even hit which makes me think that the entry point just does not work.
Making a syntax error - it didn't compile and didn't run
which means my program did compile and did run before.
Completly undoing everything I did after the last running build - Same Result. it worked before but i guess not anymore
Changing my entry point from WinMain to int main() -
cmd window was created but no signs of code executing.
Doing std::cout on the first line(with cmd window) - Same Result
The only thing that worked was commenting the whole file with the entry point and just writing :
#include <iostream>
int main() {
int i;
std::cout << "hello";
std::cin >> i;
}
Anyone knows what can make such a weird behavier ?
You probably have an infinite loop in some static initialisation code.
If you hit pause in the debugger it will show you where the problem lies.
How can I set and get the text from a RichEditBox in an Windows 8 C++ App.
I already tried these two approaches, but the program keeps crashing at runtime
cpp
contentText->Document->Selection->GetTextViaStream(Windows::UI::Text::TextGetOptions::FormatRtf, outstream);
contentText->Document->GetText(Windows::UI::Text::TextGetOptions::FormatRtf, tempOutput);
.h
private:
Platform::String^* tempOutput;
Windows::Storage::Streams::IRandomAccessStream^ outstream;
If you program crashes, that's a good thing. It doesn't actually "crash". It throws an exception and your debugger, once attached, will catch it and tell you exactly what went wrong. Next time, start your application with F5. Once it crashes, the debugger will show you what line the problem is in and you can watch all variables to check what went wrong.
In this case, make sure that
contentText is not NULL
Document is not NULL
tempOutput is initialized to a real object
Example:
Platform::String^ tempOutput = gcnew Platform::String();
I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}
I am now trying to use this Application Verifier debugging tool, but i am stuck, first of all: it breaks the program at a line that is simple variable set line (s = 1; for example)
Secondly, now when i run this program under debugger, my program seems to have changed its behaviour: i am drawing image, and now one of the colors has changed o_O, all those parts of the image that i dont draw on, has changed the color to #CDCDCD when it should be #000000, and i already set the default color to zero, still it becomes to #CDCDCD.
How do i make any sense to this?
Here is the output AV gave me:
VERIFIER STOP 00000002: pid 0x8C0: Access violation exception.
14873000 : Invalid address causing the exception
004E422C : Code address executing the invalid access
0012EB08 : Exception record
0012EB24 : Context record
AVRF: Noncontinuable verifier stop 00000002 encountered. Terminating process ...
The program '[2240] test.exe: Native' has exited with code -1073741823 (0xc0000001).
Typically when breakpoints are hit like this (via AV or an unhandled exception, etc.) inside a debugger, there is a green arrow pointing to a line of code. That arrow is pointing to the next statement to execute when the thread returns from the current function. Perhaps this green arrow is pointing to the line where you wrote "s = 1", but really the offending code is the line above it. Now I can't see your code so I can't exactly know for sure and I don't have enough rep to post a comment - but this is something that is easy to check the next time the breakpoint is hit.
I am willing to bet that s is NOT a "simple" variable. I'm much more likely to believe it's something like this:
class Foo;
int s;
void Bar() {
s = 1;
}
};
Sure, it looks like a simple s=1 statement, but in reality it is a this->s=1 statement. And if this is an invalid pointer, this->s isn't a proper variable either.