Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Development ➜ Memory leaks
Memory leaks

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Mon 27 Sep 2010 12:12 AM (UTC)
Message
Now that we are on a bit of a roll here, perhaps you guys with more modern IDEs can help find these leaks. After opening MC and opening a world file (but not actually connecting to a MUD) and then closing, I get this:


Detected memory leaks!
Dumping objects ->
{56520} normal block at 0x0259E740, 1 bytes long.
 Data: < > 02 
{56519} normal block at 0x0259E6E8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{56518} normal block at 0x0259E6A0, 1 bytes long.
 Data: < > 01 
{56517} normal block at 0x0259E648, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{56516} normal block at 0x0259E600, 1 bytes long.
 Data: < > 00 
{56515} normal block at 0x0259E5A8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{51271} normal block at 0x023E09C0, 1 bytes long.
 Data: < > 02 
{51270} normal block at 0x024E0200, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{51269} normal block at 0x023E45E0, 1 bytes long.
 Data: < > 01 
{51268} normal block at 0x024E01A8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{51267} normal block at 0x023E3EA8, 1 bytes long.
 Data: < > 00 
{51266} normal block at 0x024E0150, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{47502} normal block at 0x023D6D68, 1 bytes long.
 Data: < > 02 
{47501} normal block at 0x02459268, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{47500} normal block at 0x022720F0, 1 bytes long.
 Data: < > 01 
{47499} normal block at 0x02459210, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{47498} normal block at 0x0226EAE8, 1 bytes long.
 Data: < > 00 
{47497} normal block at 0x024591B8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{43672} normal block at 0x02263560, 1 bytes long.
 Data: < > 02 
{43671} normal block at 0x023CC308, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{43670} normal block at 0x0225D758, 1 bytes long.
 Data: < > 01 
{43669} normal block at 0x023CC2B0, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{43668} normal block at 0x02254C18, 1 bytes long.
 Data: < > 00 
{43667} normal block at 0x023CC258, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{34445} normal block at 0x02107110, 1 bytes long.
 Data: < > 02 
{34444} normal block at 0x02222340, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{34443} normal block at 0x02102F80, 1 bytes long.
 Data: < > 01 
{34442} normal block at 0x022222E8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{34441} normal block at 0x02102B38, 1 bytes long.
 Data: < > 00 
{34440} normal block at 0x02222290, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{30635} normal block at 0x020F0788, 1 bytes long.
 Data: < > 02 
{30634} normal block at 0x0217A948, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{30633} normal block at 0x0210DEC8, 1 bytes long.
 Data: < > 01 
{30632} normal block at 0x0217A8F0, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{30631} normal block at 0x020F7770, 1 bytes long.
 Data: < > 00 
{30630} normal block at 0x0217A898, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{26290} normal block at 0x020E4080, 1 bytes long.
 Data: < > 02 
{26289} normal block at 0x020E4028, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{26288} normal block at 0x020E3FE0, 1 bytes long.
 Data: < > 01 
{26287} normal block at 0x020E3F88, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{26286} normal block at 0x020DEC28, 1 bytes long.
 Data: < > 00 
{26285} normal block at 0x020E3F30, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{20014} normal block at 0x02012638, 1 bytes long.
 Data: < > 02 
{20013} normal block at 0x020125E0, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{20012} normal block at 0x02012598, 1 bytes long.
 Data: < > 01 
{20011} normal block at 0x02012540, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{20010} normal block at 0x0200C970, 1 bytes long.
 Data: < > 00 
{20009} normal block at 0x020124E8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{10148} normal block at 0x01D70038, 1 bytes long.
 Data: < > 02 
{10147} normal block at 0x01D6FFE0, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{10146} normal block at 0x01D6FF98, 1 bytes long.
 Data: < > 01 
{10145} normal block at 0x01D6FF40, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{10144} normal block at 0x01D6FEF8, 1 bytes long.
 Data: < > 00 
{10143} normal block at 0x01D6FEA0, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1185} normal block at 0x011BD5F0, 1 bytes long.
 Data: < > 02 
{1184} normal block at 0x0122B8A8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1183} normal block at 0x0121D810, 1 bytes long.
 Data: < > 01 
{1182} normal block at 0x0122B850, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1181} normal block at 0x011BBC30, 1 bytes long.
 Data: < > 00 
{1180} normal block at 0x0122B7F8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
Object dump complete.
The thread 0xDD0 has exited with code 0 (0x0).
The thread 0xE48 has exited with code 0 (0x0).
The thread 0xE68 has exited with code 0 (0x0).
The thread 0xE24 has exited with code 0 (0x0).
The thread 0xE5C has exited with code 0 (0x0).
The thread 0xE0C has exited with code 0 (0x0).
The thread 0xE4C has exited with code 0 (0x0).
The program 'C:\source\mushclient\WinDebug\MUSHclient.exe' has exited with code 0 (0x0).


If I don't open a world file at all (but just open and close the program) I get this:


Detected memory leaks!
Dumping objects ->
{10146} normal block at 0x01D6FF40, 1 bytes long.
 Data: < > 02 
{10145} normal block at 0x01D6FEE8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{10144} normal block at 0x01D6FEA0, 1 bytes long.
 Data: < > 01 
{10143} normal block at 0x01D6FE48, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{10142} normal block at 0x01D6FE00, 1 bytes long.
 Data: < > 00 
{10141} normal block at 0x01D6FDA8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1185} normal block at 0x011BD5F0, 1 bytes long.
 Data: < > 02 
{1184} normal block at 0x0122B8A8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1183} normal block at 0x0121D810, 1 bytes long.
 Data: < > 01 
{1182} normal block at 0x0122B850, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1181} normal block at 0x011BBC30, 1 bytes long.
 Data: < > 00 
{1180} normal block at 0x0122B7F8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
Object dump complete.
The thread 0x32C has exited with code 0 (0x0).
The thread 0xF58 has exited with code 0 (0x0).
The thread 0xF8C has exited with code 0 (0x0).
The thread 0x2B8 has exited with code 0 (0x0).
The thread 0xC60 has exited with code 0 (0x0).
The thread 0xF1C has exited with code 0 (0x0).
The program 'C:\source\mushclient\WinDebug\MUSHclient.exe' has exited with code 0 (0x0).


And if I just open the program (but no world files) and with the spell checker disabled, I get this:


Detected memory leaks!
Dumping objects ->
{1185} normal block at 0x011BD5F0, 1 bytes long.
 Data: < > 02 
{1184} normal block at 0x0122B8A8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1183} normal block at 0x0121D810, 1 bytes long.
 Data: < > 01 
{1182} normal block at 0x0122B850, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
{1181} normal block at 0x011BBC30, 1 bytes long.
 Data: < > 00 
{1180} normal block at 0x0122B7F8, 28 bytes long.
 Data: <                > 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 
Object dump complete.
The thread 0xFDC has exited with code 0 (0x0).
The thread 0xFF4 has exited with code 0 (0x0).
The thread 0xD38 has exited with code 0 (0x0).
The thread 0xF60 has exited with code 0 (0x0).
The thread 0x4C0 has exited with code 0 (0x0).
The thread 0xF90 has exited with code 0 (0x0).
The program 'C:\source\mushclient\WinDebug\MUSHclient.exe' has exited with code 0 (0x0).


Unfortunately it isn't telling me what these 28 byte and 1 byte blocks are. Maybe the more modern IDE will?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #1 on Mon 27 Sep 2010 12:40 AM (UTC)
Message
I've seen some of those myself, and I couldn't figure out what they were either - but I didn't really put much effort into finding the cause either.

There is one memory leak I 'may' have introduced with the themeglue.h header I wrote, which is that I never call FreeLibrary() for the uxtheme stuff - I load it once, the first time it is needed, but just let Windows (implicitly) take care of the FreeLibrary() when MUSHclient terminates.

You can try adding the following snippet to themeglue.h, and calling THEMEGLUE_FREE() just before process termination to see if it clears up one of those memory leak warnings you are getting.

#define THEMEGLUE_FREE() if (HModUXT != NULL) { FreeLibrary(HModUXT); HModUXT = NULL; }


P.S.: Please merge this commit: http://github.com/worstje/mushclient/commit/536c79bbe3c895c1819d7c4c455db23642ac8961

All the file juggling broke my build again.
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #2 on Mon 27 Sep 2010 01:01 AM (UTC)
Message
Didn't make any difference. Had to juggle stuff around because you had a variable assigned in a .h file which only works if it is ever only included once.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #3 on Mon 27 Sep 2010 01:08 AM (UTC)
Message
Weird. I am pretty sure I put #ifndef guards around the entire themeglue.h file, which should protect against that kind of thing, right?

Edit: Right, multiple compilation units. I knew I hated C++ with a good reason.
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #4 on Mon 27 Sep 2010 01:26 AM (UTC)
Message
Basically you just can't put global variables into .h file - they get multiply defined.

It's actually quite a pain. I think the stdafx.h and stdafx.cpp work around that (maybe).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Tsunami   USA  (204 posts)  Bio
Date Reply #5 on Mon 27 Sep 2010 10:37 PM (UTC)

Amended on Mon 27 Sep 2010 10:40 PM (UTC) by Tsunami

Message
Why aren't there file and line numbers for the object dumps? I saw you committed a change to DEBUG_NEW, so I assume thats how you got the dump? I've never used it personally, but I thought you got more info from it.
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #6 on Mon 27 Sep 2010 11:52 PM (UTC)
Message
Well I spent quite a few hours trying to answer that yesterday.

I think it is because the memory is allocated in a C file rather than a C++ one. One case seems to be the lbc.c library, where it allocates the numbers zero, one and two, each time you open the library (which happens more than once).

I tried to make that allocation happen once only, then got an access violation on closing miniwindows, which seems a random unrelated thing. Except insofar as they both used memory.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Tsunami   USA  (204 posts)  Bio
Date Reply #7 on Tue 28 Sep 2010 12:27 AM (UTC)

Amended on Tue 28 Sep 2010 12:31 AM (UTC) by Tsunami

Message
Does the following link contain anything you havent tried?

http://stackoverflow.com/questions/1567866/visual-studio-2008-c-memory-leak-detection-not-showing-file-method-location

From, the post, why not stick DEBUG_NEW in your precompiled header so everything should have access to it rather than on a file by file basis?
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #8 on Tue 28 Sep 2010 12:45 AM (UTC)
Message
That was the way the generated source did it, so who am I to doubt them? Besides, each file redefines the name of the file, like this:


#undef THIS_FILE
static char BASED_CODE THIS_FILE[] = __FILE__;


That link has slightly new material, but I have to tell you I spent about 2 hours just getting around linking problems. If you change the order of things in stdafx.h slightly you get "multiple defines" on certain libraries. The fixes suggested by Microsoft didn't work in my case. Grrr.

Thanks for the suggestions though, eventually we will get somewhere.

I suspect, fairly strongly, that some of the allocations are in the auxilliary libraries. For example, I found a couple done by the lbc library. However my attempted fix caused an access violation for reasons that are still unclear.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #9 on Tue 28 Sep 2010 12:50 AM (UTC)
Message
Tsunami said:

From, the post, why not stick DEBUG_NEW in your precompiled header so everything should have access to it rather than on a file by file basis?


Also some files don't use the precompiled header - particularly things like the sqlite library, which could be the place the problem is in the first place.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #10 on Tue 28 Sep 2010 01:56 AM (UTC)
Message
I just saw you commit fixups for the memory leaks, which ironically were the same things I was pinning down and preparing a commit for. Glad you beat me to them though - means I was on the right track. :)

If I spot any more memory leaks, I'll go chase those down still, but it looks good right now. :)
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

32,791 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home