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.
Related
I have a c++ program compiled with MinGW which links to libmicrohttpd to run a webserver. It normally functions correctly, but I am trying to do some robustness testing and for my current test I have tried to disable the network interface. This results in the program crashing with the dialog box: "MyProgram.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Rather than debug the program and potentially its dependencies, for my purposes, it would be fine if it would just crash silently without making the dialog box (I have another component that is meant to restart it). Is this possible to do via some sort of manifest or Windows API call?
It turns out there is a Windows API function called SetErrorMode. Passing the parameter SEM_NOGPFAULTERRORBOX will prevent the error dialog from being displayed on a crash.
There is also the RegisterApplicationRestart function which can be used to have Windows restart an application in the event of a crash (or other configurable reasons).
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.
I have Direct3D rendering library compiled with VS2008. The another application (built with VS2008) uses my library and everything works fine.
Recently, parent application was moved to VS2010 but my library is still being built under VS2008. And still everything works fine BUT one call on only ONE sprite.
D3DXSprite->Draw method crashes in D3DX9_43.dll in D3DXCore::CSprite::Draw() method. And it occurs only when I'm trying to draw a specific element from texture.
I've also tried to rebuild my library under VS2010, but no success. Crash still occurs.
Any ideas?
Thanks!
This may not be want you want to hear, but all I can suggest for debugging something like this is the liberal use of break points and special debugging if-statements.
Place a try-catch statement around the render function that is failing and place a breakpoint in the catch block.
You may need to add some counters and debugging variables so that you can monitor the size/cont of your data structures vs. what your rendering code actually processed.
If you still don't have any hints, it's time to temporarily fork your code (copy it) and simplify. Start ripping out chunks of code to see if it still fails. Eventually you'll narrow it down.
Good luck.
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.
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.