From: SourceForge.net <no...@so...> - 2004-07-25 19:06:13
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2681615 By: johngaughan I cannot reproduce this. I even put that code in a loop and executed it 100,000,000 times just to be sure. No leak. What versions of MinGW and libstdc++ are you using? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-25 20:21:24
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2681679 By: benibela minGW is 3.2 (mingw special 20020817-1) and libtdc++ is 5.0.0, both from the newest dev-cpp. When I run the code twice or more often, has it the same size, only if i make the text longer, then it gets bigger. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-25 23:17:05
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2681827 By: chicares > If i write create and destroy an std::string object > there is always a memory leak Since 'johngaughan' reports that he cannot reproduce the problem, can you explain why you believe there is a leak? Maybe there's a problem with your leak-detection software. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-26 05:28:46
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2682070 By: adah Probably it is (again) caused by the pooling feature of libstdc++. Try running again after "set GLIBCPP_FORCE_NEW=1". ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-26 09:46:19
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2682273 By: benibela >Since 'johngaughan' reports that he cannot >reproduce the problem, can you explain why >you believe there is a leak? Maybe there's a >problem with your leak-detection software. I actually don't think in the stl is a leak, more that i should call some deinitialization function. My leak finder is the Trace alloc library from Erik Rydgren. > Try running again after "set GLIBCPP_FORCE_NEW=1" How goes that? Should i write "#define GLIBCPP_FORCE_NEW 1" in the source file, or "set GLIBCPP_FORCE_NEW=1" in the autoexec.bat? Both don't work. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-27 02:14:28
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2683854 By: adah My test session of a string* s = new string("Hello") delete s; scenario (seen similar things as yours, but GLIBCPP_FORCE_NEW worked): ----------------------------------------- C:\TEMP>gcc -v Reading specs from D:/mingw-gcc3/bin/../lib/gcc-lib/mingw32/3.2.3/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gcc version 3.2.3 (mingw special 20030504-1) C:\TEMP>g++ test.cpp debug_new.cpp C:\TEMP>a Leaked object at 004A4008 (size 960, <Unknown>:0) C:\TEMP>set GLIBCPP_FORCE_NEW=1 C:\TEMP>a C:\TEMP> ----------------------------------------- Debug_new is my own leak detector. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-27 22:14:09
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2685506 By: benibela You can see, here it doesn't work: ========================== T:\>gcc -v Reading specs from C:/DEV-CPP/BIN/../lib/gcc-lib/mingw32/3.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable -languages=f77,c++,objc,ada --disable-win32-registry --disable-shared Thread model: win32 gcc version 3.2 (mingw special 20020817-1) T:\>gdb GNU gdb 5.1.1 (mingw experimental) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mingw32". (gdb) file test.exe Reading symbols from test.exe...done. (gdb) run Starting program: T:\test.exe warning: test warning: Leak of 640 bytes detected: TEST!0x00420D52 : ? TEST!0x004210AD : ? TEST!0x00419BE7 : ? TEST!0x00419567 : ? TEST!0x0041B144 : ? Memory statistics ----------------- Total allocations: 8 Max concurrent allocations: 7 Program exited normally. (gdb) quit T:\>set GLIBCPP_FORCE_NEW=1 T:\>gdb [..] (gdb) file test.exe Reading symbols from test.exe...done. (gdb) run Starting program: T:\test.exe warning: test warning: Leak of 640 bytes detected: TEST!0x00420D52 : ? TEST!0x004210AD : ? TEST!0x00419BE7 : ? TEST!0x00419567 : ? TEST!0x0041B144 : ? Memory statistics ----------------- Total allocations: 8 Max concurrent allocations: 7 Program exited normally. ============================ strange, could you send me your detector, please? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-28 03:51:40
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2685812 By: adah My detector is at http://sourceforge.net/projects/nvwa/ But it won't help since you are using an old gcc release. It is too old. Please upgrade to at least GCC 3.2.3. I know that GCC 3.2 and earlier does not honour GLIBCPP_FORCE_NEW. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-28 16:16:20
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2686830 By: benibela juhu, thank you, after installing it is away. But was it a real leak, or only an illusion of one? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-29 04:44:57
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2687782 By: adah It is "illusion". Libstdc++-v3 grabs the memory in chunks, and it does not return it on program exit because it serves no good except to satisfy a leak detector. The safest way to check this is repeat many times the operation that you suspect has problems: if memory does not grow, it has no problems. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-29 10:03:10
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2688045 By: benibela Thank you again ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-07-29 20:18:14
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2688985 By: now3d I would not gamble on the OS tracking heap allocations and recovering those entries not explicitly released. Take MS win9x for example. That hemorrhaged memory in this way from my experience. Deconstructing and releasing costs noticeably nothing, it would be better for libstd++ not to take this short cut. now3d ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: John G. <jo...@jo...> - 2004-07-31 18:25:07
|
SourceForge.net wrote: > I would not gamble on the OS tracking heap allocations and recovering > those entries not explicitly released. Take MS win9x for example. > That hemorrhaged memory in this way from my experience. The old DOS-based Windows (95-ME) memory manager is full of holes, but NT-based Windows, especially starting with 2000, are fairly bulletproof. I have done a bit of programming in 2000 and XP and have yet to have one of my programs screw things up to the point that memory is screwed up after my program is done running. > Deconstructing and releasing costs noticeably nothing, it would be > better for libstd++ not to take this short cut. Very true, especially when deallocating small numbers of objects or larger objects. Deconstructing and deallocating a large number of small objects can be noticeable, but I have the attitude that a programmer should do the right thing even if it is a little bit slower. I guess that is my Java training showing through ;-) -- John Gaughan http://www.johngaughan.net/ jo...@jo... |
From: SourceForge.net <no...@so...> - 2004-07-29 21:42:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2689099 By: chicares > it would be better for libstd++ > not to take this short cut It's configurable: http://gcc.gnu.org/onlinedocs/libstdc++/20_util/allocator.html Does that leave a problem unaddressed? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |