nvwa-users Mailing List for Stones of Nvwa
Status: Beta
Brought to you by:
adah
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Yongwei Wu <wuy...@gm...> - 2014-08-12 14:52:19
|
For GCC, you probably want to use the GCC-specific macro. In your case, add the following to the command line: -D_DEBUG_NEW_PROGNAME =\"gen.exe\" Please be aware there are still possibilities debug_new cannot catch the file/line information, if it is from a system library. On 12 August 2014 13:09, Ben Rendel <be...@wi...> wrote: > Hi, > > > > This is my compile/link (MinGW) > > > > g++ -g -O0 -ggdb -std=c++11 -static-libgcc > -static-libstdc++ -I ./SRC ./SRC/Gmain.cpp "D:\Mingw Leak > Detector\nvwa-1.0\nvwa-1.0\nvwa\debug_new.cpp" -o gen.exe -I"D:\Mingw > Leak Detector\nvwa-1.0\nvwa-1.0\nvwa" -L"D:\Mingw Leak > Detector\nvwa-1.0\nvwa-1.0\nvwa" -U__STRICT_ANSI__ > > > > the report looks like > > Leaked object at 0x20013630 (size 69, 0x44e308) No file/line info > > > > I would appreciate your comment to make it work > > > > Thanks > > Ben > > > > > ------------------------------ > <http://www.avast.com/> > > This email is free from viruses and malware because avast! Antivirus > <http://www.avast.com/> protection is active. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Nvwa-users mailing list > Nvw...@li... > https://lists.sourceforge.net/lists/listinfo/nvwa-users > > -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Ben R. <be...@wi...> - 2014-08-12 05:15:17
|
Hi, This is my compile/link (MinGW) g++ -g -O0 -ggdb -std=c++11 -static-libgcc -static-libstdc++ -I ./SRC ./SRC/Gmain.cpp "D:\Mingw Leak Detector\nvwa-1.0\nvwa-1.0\nvwa\debug_new.cpp" -o gen.exe -I"D:\Mingw Leak Detector\nvwa-1.0\nvwa-1.0\nvwa" -L"D:\Mingw Leak Detector\nvwa-1.0\nvwa-1.0\nvwa" -U__STRICT_ANSI__ the report looks like Leaked object at 0x20013630 (size 69, 0x44e308) No file/line info I would appreciate your comment to make it work Thanks Ben --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Yongwei Wu <wuy...@gm...> - 2010-03-09 03:10:07
|
Please update to the latest CVS version available here: http://sourceforge.net/projects/nvwa/develop The verbose information will then include the allocation file. Optionally, if you do not use placement new, you can define _DEBUG_NEW_TYPE=0 to get the old behaviour, which may give you better output for verbose information. Best regards, Yongwei On 8 March 2010 22:51, <mr...@po...> wrote: > Hi, > > I finally managed to make the Nvwa memory leak detector working in my wxWidgets project (Windows, MinGW 4.4.1-dw2). > I've tried MPatrol before but with no success. > > My question is: Am I missing something that (with new_verbose_flag==true) ongoing allocation/deallocation report misses file names and line numbers? > In final leakage report everything looks OK. > Here's an example: > > (...) > new: allocated 02D9BAA0 (size 4, 00420779) > (...) > Leaked object at 02D9BAA0 (size 4, C:\Documents and Settings\mrupio\Projects\test\src\testApp.cpp:149) > (...) > > Thanks, > mrupio > > > ------------------------------------------------- > Atrakcyjne mieszkania i działki. Sprawdź oferty! > http://link.interia.pl/f260b > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Nvwa-users mailing list > Nvw...@li... > https://lists.sourceforge.net/lists/listinfo/nvwa-users -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: <mr...@po...> - 2010-03-08 15:06:45
|
Hi, I finally managed to make the Nvwa memory leak detector working in my wxWidgets project (Windows, MinGW 4.4.1-dw2). I've tried MPatrol before but with no success. My question is: Am I missing something that (with new_verbose_flag==true) ongoing allocation/deallocation report misses file names and line numbers? In final leakage report everything looks OK. Here's an example: (...) new: allocated 02D9BAA0 (size 4, 00420779) (...) Leaked object at 02D9BAA0 (size 4, C:\Documents and Settings\mrupio\Projects\test\src\testApp.cpp:149) (...) Thanks, mrupio ------------------------------------------------- Atrakcyjne mieszkania i działki. Sprawdź oferty! http://link.interia.pl/f260b |
From: Yongwei W. <wuy...@gm...> - 2008-10-10 02:51:36
|
2008/10/10 Cody, Brian <bc...@kn...>: >>2008/10/8 Cody, Brian <bc...@kn...>: >>> Also I've noticed that the output from addr2line can be slow when >>> several (thousand) runs of the application are required. One >>> solution I found is to call addr2line with multiple addresses. >>> Another would be to build addr2line from binutils and link in the >>> objects, however this might bring in difficulty since addr2line >>> itself does allocations and frees. I suppose that as long as the >>> new_verbose_flag is off there won't be an issue, but I was >>> wondering if anyone else has already tried anything to tackle >>> this. > >> Since addr2line runs in another process, whether it allocates >> memory or not does not matter. The need to cache the addresses is >> the real challenge. You can see that I only dare to cache to most >> recent result. What you wish is even more difficult: you basically >> forbid debug_new to report the error in real time. I do not have a >> good solution yet. > > Actually I meant that if I linked in the necessary binutils objects > (bucomm.o, version.o, filemode.o, addr2line.o), then I could call > addr2line directly within the same process. Sorry for my carelessness. I did not try this, but this sounds very intersting. I never tried building binutils myself. Is it difficult to build on Windows (which is my main working platform)? It also seems to make using debug_new a little more complicated. Probably I have to provide a Makefile and let people use a pre-built .a when using with GCC. More thoughts? Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Cody, B. <bc...@kn...> - 2008-10-09 17:29:16
|
>2008/10/8 Cody, Brian <bc...@kn...>: >> Howdy! >> >> This tool seems great so far, just a couple questions: >> >> (Sourced from version 0.8.1) >> Debug_new.cpp in free_pointer, line 535 reads: >> print_position(_DEBUG_NEW_CALLER_ADDRESS, 0); >> >> The _DEBUG_NEW_CALLER_ADDRESS at this point returns the caller to >> free_pointer, which is always a function inside debug_new itself. The >> pointer to whoever called that other function is passed into free >> pointer via a variable called 'pointer'. Shouldn't this line actually >> read: >> print_position(pointer, 0); >> ? Otherwise the output from addr2line will just tell us which operator >> delete called the function. > >Thanks for the good catch. It should be: > > print_position(addr, 0); > >Please update (and test) on your side first. I'll double-check and >may check in a little later. Please report any problems at the same >time. Yes this does seem to fix it. >> Also I've noticed that the output from addr2line can be slow when >> several (thousand) runs of the application are required. One solution I >> found is to call addr2line with multiple addresses. Another would be to >> build addr2line from binutils and link in the objects, however this >> might bring in difficulty since addr2line itself does allocations and >> frees. I suppose that as long as the new_verbose_flag is off there >> won't be an issue, but I was wondering if anyone else has already tried >> anything to tackle this. > Since addr2line runs in another process, whether it allocates memory > or not does not matter. The need to cache the addresses is the real > challenge. You can see that I only dare to cache to most recent > result. What you wish is even more difficult: you basically forbid > debug_new to report the error in real time. I do not have a good > solution yet. Actually I meant that if I linked in the necessary binutils objects (bucomm.o, version.o, filemode.o, addr2line.o), then I could call addr2line directly within the same process. > Best regards, > > Yongwei > > -- > Wu Yongwei > URL: http://wyw.dcweb.cn/ Thanks -Brian |
From: Yongwei W. <wuy...@gm...> - 2008-10-08 15:24:36
|
2008/10/8 Cody, Brian <bc...@kn...>: > Howdy! > > This tool seems great so far, just a couple questions: > > (Sourced from version 0.8.1) > Debug_new.cpp in free_pointer, line 535 reads: > print_position(_DEBUG_NEW_CALLER_ADDRESS, 0); > > The _DEBUG_NEW_CALLER_ADDRESS at this point returns the caller to > free_pointer, which is always a function inside debug_new itself. The > pointer to whoever called that other function is passed into free > pointer via a variable called 'pointer'. Shouldn't this line actually > read: > print_position(pointer, 0); > ? Otherwise the output from addr2line will just tell us which operator > delete called the function. Thanks for the good catch. It should be: print_position(addr, 0); Please update (and test) on your side first. I'll double-check and may check in a little later. Please report any problems at the same time. > Also I've noticed that the output from addr2line can be slow when > several (thousand) runs of the application are required. One solution I > found is to call addr2line with multiple addresses. Another would be to > build addr2line from binutils and link in the objects, however this > might bring in difficulty since addr2line itself does allocations and > frees. I suppose that as long as the new_verbose_flag is off there > won't be an issue, but I was wondering if anyone else has already tried > anything to tackle this. Since addr2line runs in another process, whether it allocates memory or not does not matter. The need to cache the addresses is the real challenge. You can see that I only dare to cache to most recent result. What you wish is even more difficult: you basically forbid debug_new to report the error in real time. I do not have a good solution yet. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Cody, B. <bc...@kn...> - 2008-10-07 17:20:10
|
Howdy! This tool seems great so far, just a couple questions: (Sourced from version 0.8.1) Debug_new.cpp in free_pointer, line 535 reads: print_position(_DEBUG_NEW_CALLER_ADDRESS, 0); The _DEBUG_NEW_CALLER_ADDRESS at this point returns the caller to free_pointer, which is always a function inside debug_new itself. The pointer to whoever called that other function is passed into free pointer via a variable called 'pointer'. Shouldn't this line actually read: print_position(pointer, 0); ? Otherwise the output from addr2line will just tell us which operator delete called the function. Also I've noticed that the output from addr2line can be slow when several (thousand) runs of the application are required. One solution I found is to call addr2line with multiple addresses. Another would be to build addr2line from binutils and link in the objects, however this might bring in difficulty since addr2line itself does allocations and frees. I suppose that as long as the new_verbose_flag is off there won't be an issue, but I was wondering if anyone else has already tried anything to tackle this. Thanks |
From: Yongwei W. <wuy...@gm...> - 2008-05-22 13:45:38
|
Hi Martín, Thanks for your interest in Nvwa. 2008/5/22 Manuel Martín <mm...@ce...>: > Hello Yongwie > I'm using your nvwa. I think it's good and quick. > I tell you some comments on it. Please, forgive me it they seem to you > lowed-skilled. > > I develop on win XP > I use mingw with gcc 4.2.1 > I use wxWidgets. It is fantastic. > I use Code::Blocks IDE You forgot to mention what version of nvwa/debug_new you are using :-). My local version of debug_new.cpp is 4.12, 2007/12/31. > I attached debug_new.cpp to my project and re-build it all. > In order to get results from stderr, I execute from command line: > >C:\progs\myprog\bin\debug\myprog >res.txt 2>&1 > > > Now myprog crashes on exit. > Using gdb, I got to debug_new.cpp line 582, inside free_pointer function. On the fprintf? > When I read res.txt, I can see a lot of leaks that are deleted later > on. I gave a name to new_progname and then addr2line worked and > showed that most of those lot of leaks came from wxWidgets. They are > no really leaks because they all are deleted later. wxWidgets team > takes good care on coding without memory leaks. That is normal. There is no portable way to make sure check_leaks is called after the other memory deallocations. > Debuggin more, I see some calloc calls. But nvwa does not treat > them. So, first thought: why 'calloc' and 'realloc' are forgotten? > But 'free' is not. So, 'free' will try to manage an addr that is not > stored in new_ptr_list and crash. And what about bad code > allocating with 'malloc' and freeing with 'delete'? They will > no be catched if debug_new.h is not included. Please notice that that debug_new is a C++ memory leakage detector, and mostly works with new/delete only. There is a hack in debug_new.h to define malloc/free as macros, but they are off by default.--Are you using them? > I changed 'new_verbose_flag' to 'true', commented out lines 582-586 > and started again. Now it crash inside alloc_mem(), as soon as it > gets to line 499. I'm really lost. Another fprintf? I am lost too. Have you tried with another GCC version? > Other thoughts on my own are: > - May you documentate, out of debug_new.cpp, the usage and what > defines user should change. I think doxigen is not useful for > this. Have you checked <URL:http://wyw.dcweb.cn/leakage.htm>? However, this page is not fully updated for the improvements in Nvwa 0.8. > - addr2line is nasty slow in XP, because of opening/closing a > cmd-window for each addr. I looked inside wxExecute, a function > to do shell calls. It is no easy. Even more dificult for a > portable code like yours. True. And it is a GCC-only hack. It is useful only when one cannot include debug_new.h directly in the code. If it does not help, you may disable it by adding this in your command line: -D_DEBUG_NEW_USE_ADDR2LINE=0 I would add it to CXXFLAGS in a makefile. > - Why ALIGNMENT and TAILCHECK are needed? _DEBUG_NEW_ALIGNMENT is to ensure the memory is properly aligned, esp. when the user changes the value of _DEBUG_NEW_FILENAME_LEN. The default value of _DEBUG_NEW_FILENAME_LEN makes sure the memory is well aligned up to 64 bytes on 32-bit platforms. For default MinGW compiler settings, misalignment of 8-byte and 16-byte data types (uncommon, though) might occur if the user changed _DEBUG_NEW_FILENAME_LEN but _DEBUG_NEW_ALIGNMENT were not in effect. _DEBUG_NEW_TAILCHECK can be used to check writing-past-end errors. I.e., you allocate 16 bytes in ptr but erroneously write to p[16]. It is not on by default, since it may cause cache misses, and thus performance penalties. > - Why 'ptr' and 'pointer' point to moreless the same addr? Oh, yes. > These two questions rely on direct and quick access to > new_ptr_list, instead of using a hash for example. I don't know > how secure is this for diferent compilers. The information needed by debug_new is immediately before the memory a user allocates. Generally I use the variable 'ptr' for debug_new data, and 'pointer' for the pointer users see. AFAIK, it is secure, except the alignment issue I mentioned above. > - Why don't you check, before freeing it, ptr to be a valid addr? I checked, by looking for MAGIC. Other than that, it is hard to define 'valid'. > - You have total_mem_alloc. Please, show it. And show a > "still_allocated_mem" value. Well, total_mem_alloc is really > "still_allocated_mem" and not "max_mem_needed". There may be confusion here. However, just as you described, I do not call it 'max_mem_allocated'. Think about it as 'total memory allocated _currently_'. > - How did you decided MAGIC to be that special value? In ASCII, it is 'DBGN', short for 'DeBuG New'. > Anyhow, I like your nvwa. It catches some leaks on my code. It's > much quicker than FluidStudios MMGR. It doesn't rely on MS debug > dll. It's portable, Valgring is not. Thanks. Performance and portability are my goals, and what differentiate debug_new from other memory debuggers. > Thank you. You are welcome. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Manuel M. <mm...@ce...> - 2008-05-21 21:06:42
|
Hello Yongwie I'm using your nvwa. I think it's good and quick. I tell you some comments on it. Please, forgive me it they seem to you lowed-skilled. I develop on win XP I use mingw with gcc 4.2.1 I use wxWidgets. It is fantastic. I use Code::Blocks IDE I attached debug_new.cpp to my project and re-build it all. In order to get results from stderr, I execute from command line: >C:\progs\myprog\bin\debug\myprog >res.txt 2>&1 Now myprog crashes on exit. Using gdb, I got to debug_new.cpp line 582, inside free_pointer function. When I read res.txt, I can see a lot of leaks that are deleted later on. I gave a name to new_progname and then addr2line worked and showed that most of those lot of leaks came from wxWidgets. They are no really leaks because they all are deleted later. wxWidgets team takes good care on coding without memory leaks. Debuggin more, I see some calloc calls. But nvwa does not treat them. So, first thought: why 'calloc' and 'realloc' are forgotten? But 'free' is not. So, 'free' will try to manage an addr that is not stored in new_ptr_list and crash. And what about bad code allocating with 'malloc' and freeing with 'delete'? They will no be catched if debug_new.h is not included. I changed 'new_verbose_flag' to 'true', commented out lines 582-586 and started again. Now it crash inside alloc_mem(), as soon as it gets to line 499. I'm really lost. Other thoughts on my own are: - May you documentate, out of debug_new.cpp, the usage and what defines user should change. I think doxigen is not useful for this. - addr2line is nasty slow in XP, because of opening/closing a cmd-window for each addr. I looked inside wxExecute, a function to do shell calls. It is no easy. Even more dificult for a portable code like yours. - Why ALIGNMENT and TAILCHECK are needed? - Why 'ptr' and 'pointer' point to moreless the same addr? Oh, yes. These two questions rely on direct and quick access to new_ptr_list, instead of using a hash for example. I don't know how secure is this for diferent compilers. - Why don't you check, before freeing it, ptr to be a valid addr? - You have total_mem_alloc. Please, show it. And show a "still_allocated_mem" value. Well, total_mem_alloc is really "still_allocated_mem" and not "max_mem_needed". - How did you decided MAGIC to be that special value? Anyhow, I like your nvwa. It catches some leaks on my code. It's much quicker than FluidStudios MMGR. It doesn't rely on MS debug dll. It's portable, Valgring is not. Thank you. Manolo |
From: Yongwei W. <wuy...@gm...> - 2008-04-02 13:50:34
|
On 02/04/2008, Sharad Mittal <sha...@ya...> wrote: > > Hello, > I am developing an application in mingw that uses boost threads (instead of > pthreads). Does nvwa work with boost threads? Is there any specific > configuration required for this purpose? The simple answer is no. However, it may not be important. I would like to know, what is your purpose? Are you just intending to use some files like debug_new? In this case, since you are using MinGW and must be on Windows, and my files will use my own threading wrapper which support MinGW and Win32 threading, you may just simply enable threading in MinGW (-mthreads). Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Sharad M. <sha...@ya...> - 2008-04-01 18:26:28
|
Hello, I am developing an application in mingw that uses boost threads (instead of pthreads). Does nvwa work with boost threads? Is there any specific configuration required for this purpose? Thanks, Sharad |
From: Yongwei W. <wuy...@gm...> - 2007-12-31 09:39:08
|
Nvwa 0.8 is released, which can be downloaded at http://sourceforge.net/project/showfiles.php?group_id=104822&package_id=112773&release_id=565022 The most significant reason for this new release is the improvements in debug_new. It now supports placement new: you may use new(std::nothrow) safely with debug_new, and even new(buffer) will work in most cases (though a warning will be emitted in this case). For more information, you may browse to http://nvwa.sourceforge.net/article/debug_new.htm (under the heading "Important update in 2007" at the bottom of the page), or check the source code/documentation yourself. This change should make debug_new easier to use, with only a few more bytes' overhead per allocation. Other changes are minor. The most obvious is that I am now including the PDF manual (not PostScript) in the release, generated from a newer version of doxygen (1.5.1). It is the last day of 2007. Happy New Year! Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ |