Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
 parse description bug
Yesterday, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Exalead, Google

Members: 0
Guests: 7
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » Memory usage
Forum Rules | Mark all | Recent Posts

Memory usage
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Jan 13, 2007, 4:48 pm
Go to the top of the page
Go to the bottom of the page

thedlw

GroupMembers
Posts10
JoinedJun 10, 2006

Does anyone else know of why our codebase would grow into say 300meg of ram usuage? When it starts off it only uses maybe 30megs
       
Post is unread #2 Jan 13, 2007, 5:16 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Well not to sound like Captain Obvious, but I'd blame a memory leak. Have you got access to anything like Valgrind to try and run on it for awhile and see what gets reported?
       
Post is unread #3 Jan 13, 2007, 5:23 pm   Last edited Jan 13, 2007, 5:24 pm by thedlw
Go to the top of the page
Go to the bottom of the page

thedlw

GroupMembers
Posts10
JoinedJun 10, 2006

well yeah i know about that. and i've tried that.
All i get is either C libs or malloc.
I will be keeping to try to do that. I was just curious if anyone had noticed if anything else like this is happening.
       
Post is unread #4 Jan 13, 2007, 5:40 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Well what I'd do is launch the code in valgrind, wait until the memory usage gets crazy, then do "shutdown mud now" so you can get valgrind to tell you what it thinks leaked out.
       
Post is unread #5 Jan 13, 2007, 6:06 pm
Go to the top of the page
Go to the bottom of the page

thedlw

GroupMembers
Posts10
JoinedJun 10, 2006

hrmm i was doing that earlier. but everything in the log isn't anything that we've EVER touched. like basically i get some "Conditional jump or move depends on uninitialised value(s)" and thats about it.
       
Post is unread #6 Jan 13, 2007, 6:50 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

My guess would be the conditional jumps are from the MCCP code. You'll need to find out which zlib package your server has installed and alter the vg_suppress.supp file to match it before valgrind will ignore those.
       
Post is unread #7 Jan 14, 2007, 5:09 pm
Go to the top of the page
Go to the bottom of the page

thedlw

GroupMembers
Posts10
JoinedJun 10, 2006

well its not mccp or anything like that. i know its something comeing out of update.c but its harder to identify because we can't find any one thing that is causing it. it seems basically if the mud is up it will start just increasing memory. i've slowed it some but not stopped. i know its supposed to gain some in memory but 100megs? and valgrind isn't finding ANYTHING at all. :o(
       
Post is unread #8 Jan 15, 2007, 7:30 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Well ok. Lets look at this logically.

First off, what OS, compiler, and version of AFKMud are you trying to use? I'm assuming some form of linux since valgrind was available to you.

When the mud gets itself stuck in this situation, have you tried to do a "gdb attach pid#" where pid# is the process ID? Attaching to a running process will give you some idea of what the mud is doing at the time the memory spike starts.
       
Post is unread #9 Jan 20, 2007, 10:43 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

I've identified one possible location. The command watch code. Since this code was old Smaug and is an entirely unfixable mess the way it's currently implemented, I'm going to gut it from the code. It's been shown several times to produce infinite loops, which if not caught, could generate massive jumps in memory usage.
       
Pages:<< prev 1 next >>