|
I've done that before...takes me to DBGHEAP.C and tons of assembly code. Why won't it do as the example says and identify source code filename and line number?
|
|
|
|
|
it's not supposed to.
what happens when you look back in the call stack??
-c
Cheap oil. It's worth it!
|
|
|
|
|
I'm not sure what you mean. From the breakpoint caused by using the allocation number, I just hit F10 and single stepped through hundreds of lines of assembly code (and some of the stuff in that debug.c file) that happened to be in the crt debug stuff . I've got 40 converted files from BC to VC and I'm writing test code. I'm currently only testing a small portion of it and I don't want to have to trace every single call back if I have to do it that way when I test all of the code.
|
|
|
|
|
Debug Menu, Step Out
or View Menu, / Debug Windows / Call Stack. double click on the first file name that looks like it could be in your app.
-c
Cheap oil. It's worth it!
|
|
|
|
|
I tried it. Thank you. Seems like my leaks are strange though. Most are occuring in the iostream or STL library.
Examples. I do something like call push_back() on a STL linked list of longs or I'm doing a file open via open(filename, modePassed).
Or,I make a call to strstream like:
streamBuff << " " << setfill('0') << setw(3) << (GetPort() + 1) << setfill(' ');
Doesn't make sense.
|
|
|
|
|
it could be that the allocation number is changing from run to run. if you run your app exactly the same way a few times in a row, do the reported leaks always have the same allocation number? if not, then unfortunately, this technique won't work bceause the order of allocations is changing.
but, i'm with Tim on the fact that you've probably spent enough time on this to pay for a copy of BoundsChecker or Purify. in fact, you can download and install a trial version of Purify (14 days) and it will tell you instantly where your leaks are. www.rational.com. also, this might help you (it does memory leak detection) and comes with a 30 day trial. either way, tools like these are worth the price.
-c
Cheap oil. It's worth it!
|
|
|
|
|
Yes. I am running the App the same way everytime with no changes.
Sounds like a good investment for Boundchecker or Purify....I'll look into them. I was hoping that the integrated memory leak detection in VC++ would be good enought but apparently not.
Thanks
|
|
|
|
|
here's a better way:
add this code to your app:
#ifdef _DEBUG
void* operator new(size_t nSize, const char * lpszFileName, int nLine)
{
return ::operator new(nSize, 1, lpszFileName, nLine);
}
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
then call _CrtDumpMemoryLeaks(); at the end.
this simply adds the line number and file to the memory allocation. (only works with "new", of course)
Cheap oil. It's worth it!
|
|
|
|
|
Great. Thanks. I'll give that a try. I'm only using new anyways.
|
|
|
|
|
oh, and here's how you do it for malloc, too:
#define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
#define malloc(x) MALLOC_DBG(x)
i smell an article...
-c
Cheap oil. It's worth it!
|
|
|
|
|
Chris Losinger wrote:
i smell an article...
Looking forward to it!!!
This is very interesting stuff that I did not know. An article would be great!
---
CPUA 0x5041
Sonork 100.11743 Chicken Little
Orgasms are universal!!  -- Mike Mullikin in The Lounge 21:27 15 May '02
|
|
|
|
|
Another way to do this is to add the following define to your preprocessor settings:
_CRTDBG_MAP_ALLOC
By adding this define, all new and malloc calls are converted to the debug version of the calls.
Best regards,
John
|
|
|
|
|
that doesn't work with "new", tho. the file/line reported is in crtdbg.h, where the new version of "new" is defined, not where you actually called it.
-c
Cheap oil. It's worth it!
|
|
|
|
|
I tried building a sample program before I posted and it reported the correct information for both the malloc and the new. I didn't notice that the wizard had automagically added the DEBUG_NEW ifdef at the top of the file, thereby making it work.
|
|
|
|
|
I've tried everything you guys have suggested. The closest I am getting is that identification of line 552 in crtdbg.h. I also tried the workaround fix for it here:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q140858 but that doesn't work either.
I also found this article on the site but didn't bother downloading the code. http://www.codeproject.com/debug/debugtips.asp
It is essentially saying what you guys are saying but I see comments where it doesn't work for some people either. I'm using a console application which uses some MFC, I included afx.h, and the example says to use the /MLd option but since I am using the afx dll I had to use /MD instead. If you know how I can switch to the proper library for afx code then maybe I can use the first option.
Any help would be appreciated. Thanks for the suggestions so far.
|
|
|
|
|
At $50 an hour, after 8 hours, the amout of time you spend trying to track this down would have paid for a copy of Rational Purify.
Now go slap your boss around and get him to buy the package for you.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Try to install and use NU Mega Bounds Checker. Mail me, and I tell you a link for cracked version! 
|
|
|
|
|
Hi,
I want to update a CListBox derived class (adding many lines and deleting some). My problem is the scrollbar becomes mad (updated every time I change listbox items). I want it updated only once, after the full update. But how?
Step 1: I traced messages with MS Spy++. A WM_PAINT cause a repaint of the scrollbar, the WM_PAINT sends a ON_WM_NCPAINT(). I guess it's send directly to the scrollbar, because I do not receive a ON_WM_NCPAINT() in the listbox in that case.
Step 2: Well, maybe I need to handle the WM_PAINT and stop all WM_PAINTs while updating my CListBox (even better). I have a BOOL telling me when I'm updating.
Step 3. The WM_PAINT handler from my CListBox is empty and the default handler CListBox:OnPaint() does nothing. Now I'm stuck....
Thx for any help!
|
|
|
|
|
have you tried LockWindowUpdate/UnlockWindowUpdate ?
-c
Cheap oil. It's worth it!
|
|
|
|
|
Also look at the SetRedraw method (which is just a wrapper for WM_SETREDRAW).
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
thx Tim, SetRedraw() worked pretty good!
I still have some flickering (especially the border), but I want to add a memory DC later and I guess it's all gone then.
greets, Moak
|
|
|
|
|
Suppose I have a struct of the following type:
struct BBG_SECURITIES {
long nRecords; // Number of Entries
CString *sName; // Security Name
CString *sTicker; // Security Ticker
CString *sMarket; // Security Market
CString *sIssuer; // Issuer
CString *sCoupon; // Coupon
CString *sFrequency; // Frequency
CString *sMaturity; // Maturity Date
CString *sCurrency; // Currency
CString *sCountry; // Country
CString *sDBRS; // DBRS Bond Rating
CString *sSP; // S&P Bond Rating
CString *sMoody; // Moody's Bond Rating
CString *sBloomberg; // Bloomberg Composite Bond Rating
};
As you can see it has a combinantion of heap and stack variables inside. Is it a good practice first of all?
I expect to have no more than 1000 records. When creating a new struct of BBG_SECURITIES type, am I better off declaring it on heap or on stack? I have read somewhere that all structs are extually declared on stack (is this true?). I expect to use the struct created quite often in the program, and I will need speed but I do not want to put a drain on memory (cause I will need a lot of it for something else as well).
Thanks.
|
|
|
|
|
Unless you've got a strong reason not to do it, you'll be much better off declaring your member variables as straight CStrings (i.e. not pointers). Maintaining the integrity of your program when it comes to copying objects can be a real nightmare if you use pointers throughout. Besides, the overhead incurred by copying CString is negligible in most cases (and certainly it is if you don't expect to have more than 100 objects around.)
As for whether to store objects in the heap or in the stack, my advice is: declare everything in the stack unless you cannot (the reasons why you cannot should be obvious when you come to them.)
Another advice. Use extensively BBG_SECURITIES& (or even better const BBG_SECURITIES&) as the parms of your functions whenever it is doable.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi:
Thanks for your reply.
I am sort of a newbie, and I am not sure what you mean by that, and what it actually does:
>Another advice. Use extensively BBG_SECURITIES& (or even better const >BBG_SECURITIES&) as the parms of your functions whenever it is doable.
Thanks
|
|
|
|
|
OK. Suppose you've got some function like this:
void PrintSecuritiesData(BBG_SECURITIES bbgs); Whenever you call this function, a temporary copy of the BBG_SECURITIES passed is made and pushed onto the stack. If the function happens not to change the object, you can safely replace it with:
void PrintSecuritiesData(const BBG_SECURITIES& bbgs); that does not trigger any copying at all. These are called references, and in may ways act like "hidden pointers". If you've got some C++ tutorial or book check references out to learn more about them.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
