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
Related
I'm making an application in C++ to list all the applications the user has launched in the past few hours. One of the methods I'm trying to implement is using memory in explorer which lists the recently executed executables.
For example, in Process Hacker, I would simply go into explorer's memory and search for pcaclient, double click on the first result and I have my data.
Here's my code for the C++ version (using this built in code brackets function didn't work properly:
https://hastebin.com/pukojobika.cpp
However, when I restart explorer, the memory address changes every time. (in the case of the code above, 0x127d02d0. How would I go about searching for the PCACLIENT string in the memory and making sure that the resulting memory address contains data longer than 16 characters long?
Thanks.
We have a program which is proving difficult to debug. The MFC application runs fine for a few hours but over a day it will crash. Sometimes it will not throw any errors and simply exit the "dlg.DoModal()" section of our code without the user (or any obvious part of the code) closing the dialog. Other times it will crash and throw an error outside of our code and have a horrendous call stack that has nothing to do with our code, it has a lot of calls to system DLLs however.
A bit of background to our problem.
We are trying to develop a MFC bases C++ application (with a dialog). We have multiple threads and the code is rather large which makes debugging a nightmare. We have been experiencing intermittent crashes that we have been unable to locate the source of so far.
We are well past the use of breakpoints for debugging as we are pretty sure it is an issue somewhere in MFC, maybe not a bug but more a problem with the way we are using MFC.
Now we've tried simple things to help us like:
Enable all debug exceptions:
Debug -> Exceptions and then checking all the boxes so that we can
trap silly mistakes.
This proved helpful but we've now corrected all the errors it throws
within a few hours of running.
Search for memory leaks
We then tried Visual Leak Detector (which works beautifully by the
way) located here: http://vld.codeplex.com/ Our code now reports no
memory leaks so it is not an obvious memory leak issue. We have
included vld.h in the very top of our code near the entry point.
Adding Microsoft Symbol Server to obtain debug symbol files.
We then tried making our call stacks more human readable by using MS
Symbol servers shown in these tutorials:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3f1825e1-6770-48c0-91b0-12d8946ab259/2-how-do-i-configure-visual-studio-to-use-microsoft-symbol-server?forum=vsdebug and http://support.microsoft.com/kb/311503
This ultimately did nothing as it still doesn't tell you enough about any errors.
Using the Thread window to see all call stacks, and using the
Parallel Stack window
We have been using the Thread and Parallel stack windows to aid our
debugging but ultimately they have proved nothing more than pretty
pictures and fancily formatted call stacks that makes you feel good
more than anything. We have been using the tutorial here which has
been very handy
http://www.codeproject.com/Articles/79508/Mastering-Debugging-in-Visual-Studio-A-Beginn
Now for the more interesting things we've tried that do not throw errors straight away but can be detected as problems:
GDI Objects not being destroyed
This one is not obvious in VS2010 as an issue. Basically if you use a call like "CDC* pDC = lChild->GetDC();" and do not use the call "ReleaseDC(pDC);" then you have just created a GDI Object that will not be destroyed until your program terminates. VS2010 is a bit dumb in this regard and will keep creating these objects until your program crashes, and the call stack will look horrible and you will probably have no idea why it has crashed.
To find this issue, start Windows Task Manager -> Click Processes Tab -> Click the View Toolbar item -> Select Columns. Now check Handles, Threads, User Objects, and GDI Objects. Now start your program, find it's process in the list under Image Name, and watch to see if the GDI Objects column keeps growing or stabilizes.
Objects Not being destroyed
This is another not so obvious error, if you create a bitmap like this: "reinterpret_cast(LoadImage( GetModuleHandle(NULL), MAKEINTRESOURCE(IDB_BITMAPNPR), IMAGE_BITMAP, 0, 0, 0))" and assign it straight to a picture control, the bitmap will not be destroyed if you assign another bitmap to this picture control using similar code. Instead you need to assign the above to a HBITMAP variable which you then need to destroy when you are done.
This situation can also arise if you create a font or colour in a similar fashion.
Now with all that being said, we have tried all the methods above and we still can't find our issue. Sometimes our program will exit normally and we won't be given any debug info (this is usually after is has been running overnight), other times our program will lockup the PC (tested on multiple PCs), other times it will throw an error but we can't locate the culprit because it simply points to the ".DoModal()" part of our code and the rest is native windows DLLs which is useless for debugging purposes.
We suspect something is either being created and not destroyed properly but we aren't sure what and VS2010 is not telling us anything useful to point us in the right direction.
Does anyone have any ideas? How do we trap errors that aren't obvious to VS2010? Or rather how do we easily trap "GDI leaks" and the like?
Thanks in advance
Edit:
We've been using Microsoft's Application Verifier, it's found a few errors so far. To use it download it here http://www.microsoft.com/en-us/download/details.aspx?id=20028 run Application Verifier, add your .exe file in your Debug or Release directories and run the program in VS2010 as normal. VS2010 will break when Application Verifier 'sees' an error. It hasn't found anything too outrageous yet so I assume that we still have issues with our code.
The title pretty much says it all..
What I'm trying to do is write a tool that will monitor a dll file containing a plugin and when I overwrite it, by recompiling, it should automatically reload it.
I know I can make a copy, load the copy and monitor the original, but I thought there might be a better way..
If I understood it right the dll is completely loaded into memory so there shouldn't be a problem in deleting the file..
No, that's not how Windows works. Loading a DLL merely creates a memory mapped file, nothing is actually read from the file beyond the relocations (if necessary). Not until your code calls an exported function. Which causes a page fault because the code wasn't loaded yet. Now the code gets read from the file into RAM. If space is needed for other processes then the pages simply gets unmapped. Getting reloaded again on the next page fault.
The MMF puts a hard lock on the file. You can only rename it, not overwrite or delete it. That would crash the program. Release the lock with FreeLibrary().
Haven't tried it, I'm not on my Windows machine right now, but I think that Windows locks the file against writing when loading a DLL. You should check that first, can you actually overwrite the DLL (e.g. by compiling a new version) or does the compiler complain with "permission denied".
Otherwise I suppose you could use the file change notification API to achieve your goal.
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.