What could cause a "new" to fail?
Author
I have a pretty strange bug, it only happens when I''m not in debug mode in VC++. By that I mean in a Debug build but I''m not running the debugger, that''s when the crash happen (and in release too I might add). When I run the debugger, my program runs fine.
Fair enough, so I started narrowing it down with msgbox. I had first thought it was going over the bounds of an array and that it was the different memory layout that was causing it to not crash in debug more. It wasnt that, I finaly came to a "new" that was causing the error. I dont understand what could cause a new to fail, it''s not as if I didnt have enough memory. Here''s the new :
unsigned char *NewData = new unsigned char[Original.m_sizeX * Original.m_sizeY * CHANNEL];
Looks pretty basic to me. Of course I checked the values in Original to see if they were garbage but they''re correct.
Are any of the three values you are multiplying negative by any chance? What is the total number of bytes you are trying to allocate?
Author
On the precise case where it fails, I'm trying to allocate "32*22*4". Hardly something to make it crash.
EDIT : After a bit of poking around, when I change the conditions, it's another memory allocation that fails. I'm a bit puzzled. Something is really fishy here.
[edited by - Dark Rain on October 17, 2002 11:21:02 AM]
EDIT : After a bit of poking around, when I change the conditions, it's another memory allocation that fails. I'm a bit puzzled. Something is really fishy here.
[edited by - Dark Rain on October 17, 2002 11:21:02 AM]
Perhaps you can run your program outside the debugger, and attach once it crashes? Also, I''ve seen problems of this sort caused by bad goings on earlier in the program, such as writing outside the bounds of an array. Good luck!
Author
Yeah, I was thinking it might be that too, I''ve messed up somewhere before. How does one enter the debugger when he didnt start with it? Or did you mean something else by "attach".
Assuming that you are getting some sort of dialog (Unhandled Exception, GPE, GPF, etc...) and your program is still running after it crashes, do the following:
1) Make sure you are running a Debug version of your program
2) Run it and make it crash, but leave any dialogs up
3) Run VC++
4) Go to ''Build | Start Debug | Attach to Process...''
5) Pick your .exe from the list
6) Go to ''Debug | Break'' to pause your application
7) Debug as usual (call stack, watch window, memory window, etc...)
8) Fix the bug!
Good luck, and be sure to let us know what the problem was.
1) Make sure you are running a Debug version of your program
2) Run it and make it crash, but leave any dialogs up
3) Run VC++
4) Go to ''Build | Start Debug | Attach to Process...''
5) Pick your .exe from the list
6) Go to ''Debug | Break'' to pause your application
7) Debug as usual (call stack, watch window, memory window, etc...)
8) Fix the bug!
Good luck, and be sure to let us know what the problem was.
Maybe the assert(0) function would help too... I use that to run a debug build without starting the debugger, and jump in the code when something crashes...
As a sidenote, I invite you to have a look at MMGR on this site:
http://www.fluidstudios.com/publications.html
You know that everything you ''new'' must have its ''delete'' to avoid memory leaks? Well in a large proggy it gets tricky to make sure of that, MMGR is simple-as-heck to use (include the .h in the right place) and provides lots of memory-checking safety... Plus it even helped me find out some overbound/underbound errors with arrays.
(Though I''m trying to think up a way to redefine operator [] to -really- watch my arrays)
As a sidenote, I invite you to have a look at MMGR on this site:
http://www.fluidstudios.com/publications.html
You know that everything you ''new'' must have its ''delete'' to avoid memory leaks? Well in a large proggy it gets tricky to make sure of that, MMGR is simple-as-heck to use (include the .h in the right place) and provides lots of memory-checking safety... Plus it even helped me find out some overbound/underbound errors with arrays.
(Though I''m trying to think up a way to redefine operator [] to -really- watch my arrays)
Author
Thanks for the link Spacecat but I already use _CrtMemState to check for memory leaks so I''m pretty safe on that side ^_^.
I''ll try it Glyph, I didnt know you could do that, it''ll be really useful, thanks.
I''ll try it Glyph, I didnt know you could do that, it''ll be really useful, thanks.
Author
Mmmm problematic, I tried attaching to the proccess but it''s not in the list. I''m getting an "application error", it''s a memory could not be written one.
I also tried closing VC++ and running it from the .exe directly and then opening VC++ but it wont start till I closed the .exe that crashed. Odd
After a bit of research, I cant seem to attach to a process even when it''s not crashing ;(.
I also tried closing VC++ and running it from the .exe directly and then opening VC++ but it wont start till I closed the .exe that crashed. Odd
After a bit of research, I cant seem to attach to a process even when it''s not crashing ;(.
There are some cases where a process won''t be listed by default (such as a service under NT/2K)... try checking off the ''Show System Processes'' checkbox in the ''Attach To Process'' dialog.
One other thing to try that has helped me in the past is to start the program in the debugger, then enable some Exception breaks by going to ''Debug | Exceptions'' and selecting ''Stop always'' for things like ''Access Violation'' and ''Microsoft C++ Exception''. Good luck!
One other thing to try that has helped me in the past is to start the program in the debugger, then enable some Exception breaks by going to ''Debug | Exceptions'' and selecting ''Stop always'' for things like ''Access Violation'' and ''Microsoft C++ Exception''. Good luck!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
