Qt/C++ Exited with code -1073741819 (Program crashes with exception code c0000005) - c++

I'm having trouble with my program crashing. I get that "Program.exe has stopped working" windows pop-up which mentions my exception code is c0000005. When I return to the output from the application in Qt, it shows:
C:\Users\Me\Desktop\project\project-build-desktop\debug\project.exe exited with code -1073741819
I've found the line that's causing the error (I think!), though I don't know why it might. If I comment out this line, the program won't crash.
The line is:
db=newDb;
This is located in the constructor of my class wndChildWhatever which is a QMainWindow. newDb is defined in the constructor arguments as DatabaseManager *newDb and db is a private member of wndChild defined as DatabaseManager *db. This database address is passed around all over my program, and this wndChildWhatever is the only one I'm having trouble with.
The exception/crash doesn't occur when the window is opened/constructed, however. It happens when the window is closed. What's weirder is that it doesn't happen every time. Sometimes you can open the window and close it with out problem, then open it again and on the second closing, it crashes. Other times it happens the first time you try to close it.
I'm really not sure what's going on here and hope someone can assist!

The faulting line:
db=newDb;
And you say:
and db is a private member of wndChild
It sounds like your this pointer might be invalid. That is, if this happens in a method foo you are doing something like wndChild->foo() and wndChild is an invalid pointer. Therefore when it access the offset of db relative to wndChild you hit an accesses violation. (NT error code 0xc0000005, Windows-speak for a bad pointer dereference.)

Most likely it's not the db=newDb line itself that's causing the crash, but rather some other code that gets executed later on, that doesn't get executed if you don't set the db value. Have a look at the other code inside your wndChildWhatever class, and see what it is doing with the (db) value. Perhaps it is doing something naughty, like deleting it while other code is still using it?

With the line db=newDb you have two pointers to the same object. What do you do in the destructors? If you have "delete db" and "delete newDb" you delete the same object twice which may lead to a crash or not.

Try to delete the build directory and rebuild it. It worked for me, but i need to do it everytime I add a new function or member to any class. Idk why.

Related

Maya C++ API : Function causes undefined crash without entering the function

I'm currently working on a plugin to stream data from Maya to a custom 3D engine.
When I'm fetching existing data:
Point Light Function
Including the commented function above causes the Maya to crash after the plugin is succesfully initialized:
Crash Position
But the "pSendPointLightData()" function or the switch case hasn't even been called or triggered (It's not included in the MFnPlugin class or the constructor). It just crashes before reaching the next console output "checking connection".
No other console outputs before or inside the function are being triggered. It crashes directly after the else brackets triggering no other error messages.
When the function is commented out of the code, the application runs fine and is reaching the "pAllocNode()" function in the switch case.
Does anyone have any ideas why including the function magically crashes the application without being called or reached?
Is there a way to debug this since I've tried using breakpoints, console outputs, and try-catch exceptions which do not catch anything?
It seems to me that it's an undefined behavior.
The call stack didn't tell me much other than that the initializePlugin() function had been called. pSendPointLightData() was empty and only accepted a pointer reference to a MObject. The plugin was dynamically linked as a .mll file.
However, updating visual studio seems to have solved the issue.

Memory Issues Using xlslib

I'm attempting to get the xlslib library (http://sourceforge.net/projects/xlslib/) to work in my Windows MFC program (VC 2010). The Excel file generated can be somewhat large and I need to be able to write multiple Excel files without closing the dialog, which has caused some problems.
The root class is called "workbook". I initially declared:
workbook xls;
in the function that handles Excel export, but that blew up the stack. xls got too large.
Next attempt I declared m_xls in the class definition for my dialog, but I can't figure out how to clear m_xls between calls and if you run the Excel export more than once when the dialog is open, the data from the first run ends up in the second, the third run gets data from the 1st and 2nd, etc.
I tried clearing the data from the first run at the end of the export function. I looked at what was done in the deconstructor for the class to delete the data from the main data storage vector. The workbook class is very complex with many sub-classes and no matter when I try the program becomes very unstable after the first run through the Excel code (after clearing the data) and I get an assert in a thread pool function when I quit the program and a number of first chance exceptions in the output window.
Lastly I declared a workbook pointer in the class and then dynamically allocated a workbook with:
m_pxls = new workbook;
at the start of the function. At the end I deallocate with delete:
delete m_pxls;
This blows up the program with the following error message:
HEAP[Program.exe]: Heap block at 06329360 modified at 0632950A past requested size of 1a2
Windows has triggered a breakpoint in Program.exe.
This may be due to a corruption of the heap, which indicates a bug in Program.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while Program.exe has focus.
The output window may have more diagnostic information.
It looks like all that was allocated was the basic class with no data in it and all data added by the functions in xlslib went way outside the bounds of the memory allocated. Maybe I'm misunderstanding something, but don't the deconstructors for workbook and all its subclasses get called when the memory is deallocated?
I need to figure out how to do one of two things here:
1) Figure out how to re-initialize the statically declared m_xls in the class definition on further calls to the Excel code. OR
2) Figure out what is going on with the allocation and deallocation and get new/delete to work properly.
I've been programming for some time, but this gets into a nuance of memory management I've never run into before. I know I'm probably missing something obvious about new/delete I should know...
Thanks in advance

User Breakpoint Called From Code At 0X7c90120120e

I'm debugging a code in VS that I wrote in C.
For some reason, at some point it jumps to an assembly window with the following line:
int 3
And a pop up message box appears with the following message:
User Breakpoint Called From Code At 0X7c90120120e
I looked at the stack, and the command that caused that was MALLOC !
In output window:
Heap missing last entry in committed range near 22549c0
The weird thing is, when I press OK at the message then F5 to continue debugging it continues and everything works 100%. But when I try to execute the code I get a message that my project encountered some problem.
I tried cleaning my project, rebuilding, removing all breakpoints .. nothing worked.
First of all thank you all for commenting/ answering.
I solved the problem. I found out that I was trying to Free the same memory TWICE.
The reason that I didn't notice it before is that the "Free" (delete function) wasn't in the same function nor the same file as where the debugger stopped/ the breakpoint occured(on malloc).
So if anyone is having the same problem, just make sure you are not Free-ing the same memory more than once.
Possible duplicate of this stack overflow thread.And here's an explanation of this problem in this link.Hope that helps you out.

App closes while executing after compiling with errors, but while debugging it works fine!

Well. that´s the question. Just that.
I got an app made with SDL and OpenGL. SDL opens an extra window (which is the console) additional to the graphical one. When i execute i´m getting a 3 output error, the console tells me. And it gets closed (the graphical one).
But i know this happens when a SIGSEGV signal is received (don´t know how to capture it) and it appears in my IDE (Code::blocks) while debugging. But this time nothing appears, and everything works all right. But when executing it crashes..
What the...
What kind of error can i expect?. Sometimes it gets closed, sometimes it doesn´t. How to know what kind of problem i got?.
SIGSEGV is a segmentation fault, you're trying to access memory that isn't accessible to your process.
Assuming you're on a UNIXy system, you should be able to get the program to core dump and then look at the core dump in a debugger; alternatively, use a memory debugger like Valgrind to pinpoint the memory management issue that's causing this problem.

Program Doesn't Terminate Correctly

I'm writing a computer vision app (C++ and OpenCV). I am creating a GUI for it with wxWidgets - this is very simple; a button-press event calls the tracker app to begin.
My call to terminate the app (i.e. on clicking to close button) is as follows:
// Exiting the App
void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event))
{
// true is to force the frame to close
Close(true);
}
This usually works with more trivial GUI apps. However, on this occasion, the frame disappears yet, in the task manager, the process seems to continue running and holding memory. It's very annoying because if I run or debug the application and later make some changes and try to run again, without manually terminating the process beforehand, the compiler throws a link error because the .exe is
not found or not built by the last incremental link.
Tried inserting a brute force exit(1); in the onQuit method but it causes the app to crash.
I'm not sure what it is.. when running without the GUI, the app runs and terminates fine (albeit it is called slightly differently - from the main() function instead of from a button-press event handler which calls an abstract base class).
Is it possible that it is because a class is being declared with global scope? As in, in one file I have an instance of a class declared outside of any class method? Perhaps wxWidgets can't handle this?
To clarify:
The frame I'm closing is a top level frame. I had no problems with the exact same GUI code when it does not call the computer vision methods.
I haven't specifically coded any multi-threading but to begin with, I was getting an error that said "Error: Cannot initialize OLE". To fix this, I had to set wxUSE_DRAG_AND_DROP, wxUSE_CLIPBOARD, wxUSE_OLE and wxUSE_OLE_AUTOMATION to 0 (instead of 1) and then (re)compile wxWidgets.
Just wondering, is there some kind of threading going on with HighGUI that is inconsistent with WxWidgets? Has anybody else encountered similar problems?
::wxExit
void wxExit()
Exits application after calling wxApp::OnExit. Should only be used in an emergency: normally the top-level frame should be deleted (after deleting all other frames) to terminate the application. See wxCloseEvent and wxApp.
Include files
<wx/app.h>
You can also simply call the crt function exit() which will instantly shut down everything.
However, if you want to more polite than these rather brutal methods ( which you may want to do in particular if you have placed some special shut down code in wxApp::OnExit
) then you want to find the top level window and close that. To do this from anywhere in your code
wxGetApp().GetTopWindow()->Close()
Thanks for all the help, I have solved the problem. Seems fairly obvious now but couldn't figure it out at the time!
Originally, my computer vision app was called from a main function. However, with the new GUI code there is no need for a main so I replaced the original main with a shell class.
Though I had been careful to free allocated memory within the methods of my computer vision classes I had not been so careful with the original main function because once that function ended, all memory previously in use would be cleared up by the program's regular exiting.
The difference with the new GUI code is that when the shell class is finished - the program is still running. The clue was in the fact that even when the computer vision app had ended, the blue light on my webcam was still shining.
* Be sure to call cvReleaseCapture( &capture ); to free up that thread and release the hardware *
Your call to Close only closes the frame, but doesn't stop the application, because it is not the last top level window. The wxWidget contains a topic Window Deletion Overview. It states that
A wxWidgets application automatically exits when the last top level window (wxFrame or wxDialog), is destroyed. Put any application-wide cleanup code in wxApp::OnExit (this is a virtual function, not an event handler).
Is your frame the top-level frame? If not, you may have to call Close or Destroy on a top-level frame.