Okay, so, to my understanding 6Dragons is a heavily modified smaug 1.4a. That said, may have come across an odd memory leak (after talking with Dace). Below is what I could find out...any help with this is appreciated! heh

#0  0x0812d4fa in do_flee (ch=0x1020003,
    argument=0x9426b58 "P B\tø@B\tø@B\tØiP\t") at fight.c:5847
5847          los = (int)((exp_level(ch, ch->level + 1) - exp_level(ch, ch->level)) / 8);
(gdb) bt
#0  0x0812d4fa in do_flee (ch=0x1020003,
    argument=0x9426b58 "P B\tø@B\tø@B\tØiP\t") at fight.c:5847
#1  0x081351cc in damage (ch=0x9426b58, victim=0x9426b58, dam=13, dt=154)
    at fight.c:3350
#2  0x0820ff6b in do_track (ch=0x3d077, argument=0x832d4a0 "à\001")
    at track.c:234
#3  0x082189f6 in char_update () at update.c:2489
#4  0x080f10c6 in new_descriptor (new_desc=1077636104) at comm.c:1562
#5  0x080f4b49 in cleanup_memory () at comm.c:620
#6  0x402b244b in ?? ()
#7  0x40015cc0 in ?? ()
#8  0xbffff6c4 in ?? ()
#9  0xbffff698 in ?? ()
#10 0x402b244b in ?? ()
#11 0x00000002 in ?? ()
#12 0xbffff6c4 in ?? ()
#13 0xbffff6d0 in ?? ()
#14 0x40015fd8 in ?? ()
#15 0x00000002 in ?? ()
#16 0x0804a160 in ?? ()
#17 0x00000000 in ?? ()
#18 0x0804a181 in _start ()
#19 0x080f47ef in cleanup_memory () at comm.c:609
Previous frame inner to this frame (corrupt stack?)
(gdb)

Would need a little more then that to know what your thinking is a problem.

I see cleanup memory is called etc... but is this a core file? *I will assume it is* the problem with a core file is that it can become outdated (if you modify a source file before looking at the core in gdb etc... It is also hard to track down a problem that isn't easily reproduced in gdb. I would suggest using valgrind but zeno's server will shutdown valgrind fairly fast because of the amount of resources it uses (just one of those auto setup things). If you get a core again before changing anything else go ahead and use gdb to take a look at it and do bt (backtrace) like you did in this post but then do like (frame 0) and then check some of the stuff in it like (print ch->name) etc... Need to try and get as much info as possible on why it is crashing.

Yeah, sorry...mud was crashing for no apparent reason, except that I saw IMC server cutting in and out during the crashes. After each crash, mud would reload without IMC connecting until after a copyover.

I just wanted to bring this up now before I forgot, then I have somewhere to come back to when/if it crashes again. I'm thinking more when than if, just a matter of time.

Like Remcon said, watch out for putting off dealing with a crash issue from a core file while you go make other changes because you could make the core file obsolete with your other change in the meantime.

Oh, and Vladaar's not the only one of us (not even close really) running what amounts to a heavily modified Smaug 1.4a because we started with Smaug 1.4a and followed the FUSS project most of the way as we did our own other changes too. My own mud's version command shows:

Current Version of Land of Legends is 2.4.5.26.9 Pre-Release
A derivative of SmaugFUSS 1.6, SmaugFUSS 1.4, and Smaug 1.4a

The downside is that our code isn't really SmaugFUSS, let alone the current version of it, so not every fix to SmaugFUSS applies.

Conner said:

My own mud's version command shows:

Current Version of Land of Legends is 2.4.5.26.9 Pre-Release

How does your version system work? What does each digit/level signify? I only have, I think, 3 levels for my code and thought I was going overboard already. Honest question, not trying to be an ass or anything, I'm just curious.

erm...well, I've already made some changes...but, hopefully they won't matter too much in the long run. I'm gonna quit with the updates for a while and see if it'll crash again (changes made were adding a sayto command via snippet, and adding sorting option to our tradeskills lists)

Remcon said:

Would need a little more then that to know what your thinking is a problem.





I see cleanup memory is called etc... but is this a core file? *I will assume it is* the problem with a core file is that it can become outdated (if you modify a source file before looking at the core in gdb etc... It is also hard to track down a problem that isn't easily reproduced in gdb. I would suggest using valgrind but zeno's server will shutdown valgrind fairly fast because of the amount of resources it uses (just one of those auto setup things). If you get a core again before changing anything else go ahead and use gdb to take a look at it and do bt (backtrace) like you did in this post but then do like (frame 0) and then check some of the stuff in it like (print ch->name) etc... Need to try and get as much info as possible on why it is crashing.

I thought I've left valgrind running overnight and such. What kind of valgrind shutdown?

It has been quite a long time since I tried it, but normally after 5 mins or so Vladaar's mud in valgrind will be killed. I'm not sure if it is just the massive resources or what though right off. If you want I'll test it out sometime just to see what it says when it does it.

Why is cleanup_memory being called when a new descriptor is made? That's... Bad is it not? Doesn't cleanup_memory remove EVERYTHING from memory? Or does 6Dragons have a different cleanup_memory then the FUSS Bases?

GatewaySysop said:

Conner said:

My own mud's version command shows:

Current Version of Land of Legends is 2.4.5.26.9 Pre-Release

How does your version system work? What does each digit/level signify? I only have, I think, 3 levels for my code and thought I was going overboard already. Honest question, not trying to be an ass or anything, I'm just curious.

:snicker: It's actually a cheated numbering scheme in that I used to just follow SmaugFUSS' numbering scheme until I added multiclass and renamed it to Land of Legends 2 Pre-Release, since then I've upped the first number after that for each time I compile with changes to a .h file in a given day and the rest of the numbers are the date that compile took place, so the last time I made a change that involved a .h file was back in May of 2009 on the 26th and it involved enough stuff to change .h files 4 times. I've always been told that there's no real right way to do version numbering anyway, so I figure that by having a semblence to major.minor and adding a sub-minor with a date isn't a big deal. I don't think breaking it down to Major.minor.sub-minor is bad either though. Ultimately, I guess you could say that I've got the same version system you do with three levels, I've just also added a date for myself so I can see how recent it's really been. My version command also shows the date of last compile which, at the moment, shows "Most recently compiled on Apr 20 2010 at 14:14:30" but I wasn't trying to point out that I'd neglected my coding for so long (even if my dev port probably has a much more recent date) when I mentioned my version number up there.

I really do have several projects that I want to get back to working on but I've been busy with real life for awhile now and ran into a problem with my CVS system back when I switched linux flavors so I've been reluctant to bring anything new to the live port until I can get that resolved.

No Kayle it is more or less the same, that is one reason I think the core was no longer valid because of changes being made before it was looked at.

Yeah. That could be a big issue. If it's the same one that's in FUSS, then every time that's being called it's erasing everything in memory. Well, everything that the function is setup to erase from memory. Which for sure includes descriptors, characters, objects, mobiles, areas, and a bunch of other important things.

Hmm. That gdb output has to be invalid. cleanup_memory can't be called unless the game is exiting. Unless we've got one whopper of a bug in here somewhere.

Yeah, I wish I was more conversant in everything code-wise, but I'm not. So, sorry for my noobness^11, but I'll know what to do next time it crashes. I've stopped all additions that require a copyover until this is resolved, which is something I regret--but as someone said, better to get it resolved now, than later.

As for any other information asked, speak like you're talking to a little kid and include commands I may need to run. *LOL* I can gdb and bt, that's about it. >.> While I know there's a great deal more available, I'm not at all familiar with it at this point in time. I just checked the core to see if there was any change (no recent crash that I'm aware of) just to be sure, and none. Probably a waste of time, but thought I'd throw that out there. heh

Well you need to stop doing modifications period because if it crashes and you've modified the code without rebooting clean you're still going to end up with bogus backtrace data. Yes, it sucks, but it's the only good way to nail down those pesky bugs.

Samson said:

Well you need to stop doing modifications period because if it crashes and you've modified the code without rebooting clean you're still going to end up with bogus backtrace data. Yes, it sucks, but it's the only good way to nail down those pesky bugs.

So...you're saying to do a clean boot and then just go from there? (no more modifications, of course, and I even put it in the news so the players won't expect anything anytime soon heh)

Yes, stop modifying for now, reboot the game, and then wait for it to crash again. Then you should at least have a clean core to work with.

heh Okay...been done, but I see that the core is the same--I'm pretty sure this is only generated if there's a problem, so it's not really needed, but.... >.> ...wasn't wanting to delete anything that might be important, so leaving it for now. heh

Yea the core is created when there was a crash. I'm fairly sure that is an outdated core though and should be deleted. then when you get a new core check it out.

Okay, thanks! Core's deleted, now to wait for that impending crash. Hope it doesn't take too long...sucks just sitting here doing nothing waiting on this.