exception during string assignment from GDCM - c++

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.

Related

VTK 7.1.1: vtkX3DExporter exception

I am using vtkX3DExporter to export a string, but there is an exception when I'm calling GetOutputString().
Writing to a file is successful but writing to a string is not.
I am using VS2017 and my building target is an x64 dll . Another exe imports this dll and tests it like this:
// ... codes ...
exporter->SetFileName("D:\\TestFolder\\cccccccc.x3d");
exporter->Write(); // Writes to file successfully
exporter->WriteToOutputStringOn(); // Turns On "WriteToOutputString"
exporter->GetWriteToOutputString(); // Returns 1
exporter->GetOutputStringLength(); // Returns 0
exporter->GetOutputString(); // Exception here.
I can't catch this exception (I don't know why. I used try and catch blocks but my exe just crashes) so I don't know the details.
OK, I find the answer. I should call exporter->Update() before trying to get the output string.

Unhandled exception while assigning strings. C++

I'm using Visual Studio 2012 Express and I write in c++.
I have a rather weird problem with my code.
void CMap::loadMap(const std::string &MapName)
{
m_MapName = MapName; // This line is causing an error
loadMap();
}
While it compiles succesfully, it crashes on that line when I run it.
Unhandled exception at 0x003A10FC (msvcr110d.dll) in MyAdventure.exe: 0xC0000005: Access violation writing location 0xFEEEFEEE.
That's what it says. When i click Break, it directs me to that line in memcpy.asm
mov [edi],al ;U - write second byte to destination
CMap is a class which has
std::string m_MapName;
as it's member.
I've also tried to compile my code in Visual Studio 2010 Express and it works fine without any problems. I'd really want to use VS 2012 though, so I'd really like some help.
Thanks for any help.

Boost serialization assertion fail

I use boost's binary serialization and it worked well until now. I have std::list of pointers to serialize for output (oarchive) but serialization fails inside object's serialize() function with MSVC's dialog:
R6010 -abort() has been called
and such string is printed into console window:
Assertion failed: 0 == static_cast<int>(t) || 1 == static_cast<int>(t), file c:\program files\boost\boost_1_44\boost\archive\basic_binary_oprimitive.hpp, line 91
what does it mean?
Project is pretty big, sources are distributed so I cannot post it's code here, but I tried to simulate this error within simple project - there it works fine what is strange.
P.S. I use boost 1.44 with MSVC2010EE on Windows XP. When I click "retry" on "Debug Error!" window debugger shows arrow on the code line next to serialization archive << myList; line - I mean it seems like error occurred at some destructor or something.
When I make changes inside objects serialize() function - they will be applied just when I rebuild whole project (clean before compiling) - but if I just compile it (where IDE shows that all sources which include changed header are recompiled) - no changes will happen at runtime since last version (I tried with printf()) - that's strange.
Could I occasionally set some critical definitions or something?
The line in question says:
// trap usage of invalid uninitialized boolean which would
// otherwise crash on load.
It looks like at some point you are trying to serialize a bool that hasn't been initialized. Without further code we can't help you find which one.

Program crashes with 0xC000000D and no exceptions - how do I debug it?

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();
}
}

dbgrptt.c dbghook.c Iterator Error?

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.