Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2  Next
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Fri Sep 03, 2010 9:51 am   

[3.25-3.29b]Slow, severe memory leak [Revisited]
 
I'm not sure what it was (maybe the gmcp change, as that's the only thing that I use based off the recent version history), but something that changed between versions 3.24 and 3.25 have caused me to have a severe memory leak. It's quite slow, as I didn't notice it until it had reached 850MB of usage, and that was after CMUD had been running for a few hours.

I haven't been able to pinpoint it - I've disabled all my scripts and still I've seen the increase. I'm back on 3.24 right now, and I am not suffering the memory leak that I was with 3.25.

Hopefully you'll have better luck than I do at finding this leak. I'll try to provide as much information as I can as requested.

Charneus

Edit: I notice it's still there in 3.24, but it's not as prominent as it is in 3.25


Last edited by charneus on Sat Sep 25, 2010 7:09 am; edited 1 time in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Fri Sep 03, 2010 5:14 pm   
 
There is no way for me to find this without a lot more details. It's going to be something specific to your scripts. If it still happens with your scripts disabled, then try it in a blank session and see if you can find a procedure to reproduce it that I can use. It might be something in GMCP, but I haven't see the leak here. And I'm always running CMUD in debug mode with a memory leak tester running to tell me when I close CMUD if there were any leaks.
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Fri Sep 03, 2010 7:12 pm   
 
I imagine this may be what is causing the issues I've been having with CMUD slowing down. I'll also see if I can find some way to reproduce it since my first method of trying to get it to reproduce didn't work.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
Myrkul
Wanderer


Joined: 21 Aug 2008
Posts: 85

PostPosted: Sat Sep 04, 2010 5:15 pm   
 
[edit][/edit]


Last edited by Myrkul on Thu Apr 14, 2011 11:13 pm; edited 1 time in total
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Sat Sep 04, 2010 5:25 pm   
 
Well, I don't use GMCP (my MUD doesn't support it) and I've definitely noticed signs of something at least similar to a memory leak.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Sat Sep 04, 2010 6:58 pm   
 
Chamenas, do you happen to use the status window? That's a common link between Myrkul and myself...

Zugg: Myrkul and I also came across this address violation when we had the status window open, then right-clicked on the caption and chose 'Close.'

Code:
date/time         : 2010-09-04, 11:51:56, 837ms
computer name     : CHARNEUS-LAPTOP
user name         : Charneus <admin>
registered owner  : Charneus
operating system  : Windows 7 build 7600
system language   : English
system up time    : 14 hours 14 minutes
program up time   : 2 hours 54 minutes
processors        : 2x AMD Turion(tm) 64 X2 Mobile Technology TL-60
physical memory   : 930/1918 MB (free/total)
free disk space   : (C:) 26.48 GB
display mode      : 1280x800, 32 bit
process id        : $12f8
allocated memory  : 109.25 MB
executable        : cMUD.exe
exec. date/time   : 2010-09-01 15:17
version           : 3.25.0.0
compiled with     : BCB 2006/07
madExcept version : 3.0k
contact name      :
contact email     :
callstack crc     : $87c763d8, $2f5ea021, $2f5ea021
exception number  : 1
exception class   : EAccessViolation
exception message : Access violation at address 00CEB649 in module 'cMUD.exe'. Read of address 00000308.

Main ($bbc):
00ceb649 +0cd cMUD.exe     MAIN           11300 +10 TMUDForm.FormActivate
00c99da8 +04c cMUD.exe     PARENT          6311  +7 TParentForm.UpdateFocus
00c9ddef +00f cMUD.exe     PARENT          8503  +0 TParentForm.wmUpdateFocus
004bc11b +2bb cMUD.exe     Controls                 TControl.WndProc
004c011f +4fb cMUD.exe     Controls                 TWinControl.WndProc
004a267f +553 cMUD.exe     Forms                    TCustomForm.WndProc
00c3dbc8 +020 cMUD.exe     DXSounds        2128  +9 TCustomDXSound.FormWndProc
00c3c0b8 +00c cMUD.exe     DXClass          635  +1 TControlSubClass.WndProc
004bf848 +02c cMUD.exe     Controls                 TWinControl.MainWndProc
0047d4ac +014 cMUD.exe     Classes                  StdWndProc
776241f4 +016 USER32.dll                            CallWindowProcA
0071503b +0a7 cMUD.exe     aqDockingUtils  1728  +7 CallDefWndProc
00715129 +0dd cMUD.exe     aqDockingUtils  1776 +41 TaqWindowEventFilter.WndProc
0047d4ac +014 cMUD.exe     Classes                  StdWndProc
77603573 +00a USER32.dll                            DispatchMessageA
0044687d +23d cMUD.exe     madExcept                HandleException
0044d2ea +03a cMUD.exe     madExcept                InterceptAHandleExcept
0074aaa5 +0b5 cMUD.exe     aqDockingBase   7982 +13 TaqCustomDockingManager.DoActiveControlChange
77a565c6 +081 ntdll.dll                             RtlRaiseStatus
77a56452 +00a ntdll.dll                             KiUserExceptionDispatcher
004a4df7 +027 cMUD.exe     Forms                    TCustomForm.Activate
00c9f8f7 +063 cMUD.exe     PARENT          9397  +5 TParentForm.DockManagerActiveControlChange
0074aa86 +096 cMUD.exe     aqDockingBase   7980 +11 TaqCustomDockingManager.DoActiveControlChange
0074a9e4 +04c cMUD.exe     aqDockingBase   7956 +15 TaqCustomDockingManager.UpdateActiveControl
0074a92e +04e cMUD.exe     aqDockingBase   7930  +5 TaqCustomDockingManager.SetActiveControl
0073902d +025 cMUD.exe     aqDocking       6445  +3 TaqDockingControl.WMParentNotify
004bc11b +2bb cMUD.exe     Controls                 TControl.WndProc
004c011f +4fb cMUD.exe     Controls                 TWinControl.WndProc
004bf848 +02c cMUD.exe     Controls                 TWinControl.MainWndProc
0047d4ac +014 cMUD.exe     Classes                  StdWndProc
77a5642b +02b ntdll.dll                             KiUserCallbackDispatcher
77602fd7 +125 USER32.dll                            PeekMessageA
004aa757 +05f cMUD.exe     Forms                    TApplication.ProcessMessage
004aa82e +00a cMUD.exe     Forms                    TApplication.HandleMessage
004aab23 +0b3 cMUD.exe     Forms                    TApplication.Run
00e4ba8c +088 cMUD.exe     CMUD             372 +20 initialization
77241192 +010 kernel32.dll                          BaseThreadInitThunk

error details:
Right-clicked Status window bar, chose 'close'


I'm not sure if this is the cause of the leak, but I'll continue looking into it if this isn't. I will say that CMUD seemed to stop increasing once I opened up the layout without the Status window involved. Still looking into it, though.

As extra information goes, Myrkul's status window was blank, not used. Mine contained information.

Charneus

Charneus
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Sat Sep 04, 2010 7:04 pm   
 
Nope, don't use a status window. And, as of yet, have been unable to find an identifying factor for my problems which would allow it to be replicated. I'll keep looking though.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Sun Sep 05, 2010 10:43 am   
 
Don't know if this means anything, but I created a process dump of CMUD, and noticed this:


All that is gmcp variable stuff... am I wrong to think those are memory addresses being used each time CMUD 'updates' the gmcp variables instead of reusing already allocated slots? I've never done much in the way of hex editing, but I'm just checking every last option I have to find this memory leak so I can play normally again.

Charneus
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Sun Sep 05, 2010 12:39 pm   
 
The memory leak might be within the JSON library used?
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Sun Sep 05, 2010 4:27 pm   
 
There's two signs of my issues: the lagging command line and the fact that whenever I try to start a session it takes anywhere from 10-60 seconds for the session to open. What will happen is the session choice window will disappear and it will open up the chosen session, but the window will be filled with gray and nothing will happen for awhile. Eventually it will connect and the background will go black and everything goes as per normal. I've tried resetting the layout and what not, but it hasn't solved the issue, and I'm unfortunately no closer to identifying the source. Is there any information I can grab when these things are happening that will help?
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Mon Sep 06, 2010 4:05 am   
 
I'm wondering if my extra windows are causing it. Whenever I reset the layout by starting with shift, it works fine. However, I setup my layout again and voila the problem at the start happens. Also, since my windows are always open, if there was a leak there, they could easily be causing the command lag.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Mon Sep 06, 2010 9:30 pm   
 
I'm now wondering if it's anything to do with my #WAITs that I use. Right now, I have a clean session with just a few basic triggers, and then my weather script which has a #WAIT to create a new thread so it's not locking my command line when it tries to get information from the web.

I also use it in a few other places for the same reason... with the one #WAIT, I've gained 15MB over the course of 6 hours. With 8 #WAITs, I was seeing 500MB gains within the course of three.

If I recall, I had this same issue a long while back, and I think it was fixed. Myrkul said he had an extra thread running, and when he disabled the script, it no longer ate up memory.

Charneus
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Tue Sep 07, 2010 2:57 pm   
 
So, I opened up the task manager to watch memory usage as I opened CMUD. I clicked on one of my sessions with its layout of several floating windows and it gave me the whole "gray background" problem and not connecting for nearly a minute and I watched as CMUD, doing nothing on the surface but show me a blank window, skyrocketed to 158,000k mem usage. Now, since this was still below where Firefox was at, it didn't worry me so much, I had no real comparison to go off of. So I opened another session a bit later (after having closed out CMUD). This session opened normally (even though it has floating window??) and ran at about 30-50k for as long as I was playing it. Both sessions have roughly the same amount of triggers and aliases, since both share my main package for the game, and their own packages don't have much else in the way of triggers and aliases.

Both have the same window layout of a Main session window, flanked to the right by four created windows. And yet one loaded up and ran normally, while the other took nearly a moment before it would connect or show anything other than an unusual gray background. This same problem happens to another session of mine, in fact, it was getting so bad that it was causing sound and graphics to freak out while I waited for it ot fix itself for the other session, so I had to force CMUD to close, which fixed everything.
_________________
Listen to my Guitar - If you like it, listen to more

Last edited by chamenas on Tue Sep 07, 2010 6:29 pm; edited 1 time in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Tue Sep 07, 2010 5:18 pm   
 
If you are using #WAIT, run the #THREAD command to see how many background threads are active. You might be getting a bunch of stuck threads.

On the memory dump, it does look like the JSON parser is somehow not releasing some of it's memory and that might be causing the memory leak with GMCP. I'll try to do some more testing with GMCP and see if I can reproduce this.
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Tue Sep 07, 2010 5:29 pm   
 
Is there anything I can do to shed light on my problem, Zugg? So that you can look into it? I know my MUD doesn't use GMCP and so I don't, so I don't think that's related to the odd spikes in mem usage I'm seeing. The one common identifier I'm seeing so far is the layout issues, I think it may have to do with custom windows being sized differently than default, odd as that sounds.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Tue Sep 07, 2010 5:35 pm   
 
Chamenas, your problem is different than the one originally posted to this thread, so you should really create your own thread about it. This thread is about a severe memory leak in GMCP.
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Tue Sep 07, 2010 5:37 pm   
 
Well the title is just about a mem leak, which is what I suppose my problem to be. But I'll make a new thread.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Wed Sep 08, 2010 8:35 am   
 
Well, don't have multiple threads running at the same time (I have one #THREAD and the rest are #WAITs), but one oddity (I'm guessing) I found is this:

Code:
Threads:
  #   ID         Window Name          Status               Script
  -------------------------------------------------------------------------------------------------
  71             [u] Aardwolf         running             


Why is it up to 71? Last time I checked, it was 3. Shouldn't it always be 1, since it's the main window, or am I just fabricating things?

Charneus
Reply with quote
Moo
Apprentice


Joined: 10 Apr 2009
Posts: 145

PostPosted: Wed Sep 08, 2010 1:35 pm   
 
Hmm.. May be a little off topic, but:
Code:
Threads:
  #   ID         Window Name          Status               Script
  -------------------------------------------------------------------------------------------------
  1              [u] <char 1>         running             
  2              [u] <char 2>         stopped             
  3              [u] <char 3>         stopped             
  101            <char 3>             stopped

I have no #THREAD and minimal use of #WAIT/#WAITFOR. I'm wondering about one char appearing twice. I'm guessing thread 3 is the command line thread for that window, and thread 101 is something else?
That thread 101 only appears if I type #THREAD from another character's window. If I type it in char 3's window, just the first 3 threads show. Confused
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Wed Sep 08, 2010 4:34 pm   
 
The [u] in front of the thread name indicates it is the "user" command line thread. So it's normal to have one of those for each of your windows.

Charneus: This thread ID gets incremented each time you use a #WAIT command on the command line. The #WAIT causes the existing thread to be placed into the background and causes a new thread number to be created for the command line. Even running an alias from the command line that uses #WAIT will cause this. So this isn't necessarily a problem, but it does indicate that you are using #WAIT commands somewhere.

Moo: Your thread looks a bit different and might be a problem. The ID 101 thread is associated with your window and is stopped. Since there isn't any [u] at the beginning, that indicates a thread created by a trigger that used a #WAIT command of some kind. I'd definitely go ahead and kill the extra thread (#STOP 101) and see if you can trace down what script running in that window might be causing it.

However, I don't see anything in either of these #thread outputs that would explain the memory leak, so that puts it back to something related to the GMCP and JSON parser code.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Wed Sep 08, 2010 7:06 pm   
 
Zugg: Is it only when it's initiated from the command line (i.e., I have to type out the alias or type #WAIT)? Or is it any time a script uses it, period? All of the #WAITs and #THREADs are done script-wise. I never enter anything into the command line.

Charneus
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Wed Sep 08, 2010 8:48 pm   
 
It's only from stuff initiated at the command line (like an alias call). A #WAIT within a Trigger uses it's own thread and does not cause the ID of the command line thread to be incremented.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Wed Sep 08, 2010 11:25 pm   
 
Okay, because like I stated, none of my #WAITs nor the #THREAD are initiated by an alias on the command line. It's all through triggers (though two triggers call an alias with #WAIT/#THREAD in it). So would this be a bug, since I'm not executing it at the command line?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Thu Sep 09, 2010 4:34 pm   
 
Yes, it might be a bug if you can pin down how it is happening. But I doubt it has anything to do with the memory leak we are talking about here.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Thu Sep 09, 2010 5:16 pm   
 
I'm not seeing any GMCP memory leak over on Imperian, so this afternoon I'll do some testing on Aardwolf to see if there is any difference. Note that I'm just testing this by running around the MUD a lot and watching the memory usage. No scripts or anything. Just GMCP enabled with the mapper.

You did mention that it was a slow leak, but I wonder how slow. If you can do any more testing on your end, that would be a big help.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net