If you're running linux and would like to help!

[Trumpcard]

I've already corrected all the ones you reports are displaying, that was done this weekend.

New code is being pushed out now, should be available in a few hours. Sourceforge can take time to recognize the updates.

Please test with this updated version. Also, I still believe running multiple leak zones will continully overwrite the leak.out file, so you might be eliminating information by running them all concurrently in the same directory. It is definitely not appending or there would be multiple occurences of each alloc scheme mismatch.

[bobzub]

Sorry for being late. I hope I got things together properly, I had
to step away for a bit while this ran. Please let me know if this
helps at all. I asked people to zone in and out of gfaydark, which
is the zone I ran this on. Sorry if its a big large.

http://www.ubzub.com/fish-wolf/leak.out

-bobzub

[Trumpcard]

That needs to be run through leak-analyze before the results will help....

leak analyze will use gdb to isolate the code

I could try but if my binary doesnt match yours, the source lines wouldnt match up, so run it through there and post the results..

[arkaria]

bobzub
have a look at my first post of a leak.txt I gave the command you need to use. There is more info on analysing in the README

[bobzub]

grrr figures I forget something, lemme get that done.

-bobzub

[bobzub]

Apologies, here is resulting file:

http://www.ubzub.com/fish-wolf/leak.txt

hopefully I got this one right.

-bobzub

[Trumpcard]

Odd, its listing the line numbers and where they're from, but not listing the source lines...

This is obviously the older code base, pull down CVS today and test again with the updated version if you dont mind. Good tests would be having mixtures of spell casters and melees fighting, that way we'd be exercising alot of the code in spells.cpp as well.

Thanks!

This is one I havent seen... I'm guessing the way point list isnt being cleaned up properly.. Havent really messed with that code much, but I'll look into it.. How many zones was this, and how long was it running for ?

#-- Leak: counted 1150x / total Size: 23000
0x80e588a is in Mob::AssignWaypoints(unsigned short) (MobAI.cpp:1274).
	in MobAI.cpp

This one has been FIXED, we caught that one the other day in testing..

#-- Leak: counted 2x / total Size: 45404
0x80df355 is in Corpse::MakeLootRequestPackets(Client*, APPLAYER const*) (PlayerCorpse.cpp:527).
	in PlayerCorpse.cpp

Think we got all of these..

#-- Leak: counted 330x / total Size: 6600
0x80b1dd1 is in Client::Damage(Mob*, int, unsigned short, unsigned char, bool, signed char, bool) (attack.cpp:932).
	in attack.cpp

#-- Leak: counted 330x / total Size: 7590
0x80b1df7 is in Client::Damage(Mob*, int, unsigned short, unsigned char, bool, signed char, bool) (EQNetwork.h:69).
	in EQNetwork.h

#-- Leak: counted 330x / total Size: 7590
0x80b1e36 is in Client::Damage(Mob*, int, unsigned short, unsigned char, bool, signed char, bool) (attack.cpp:933).
	in attack.cpp

#-- Leak: counted 419x / total Size: 8380
0x80b31a5 is in NPC::Damage(Mob*, int, unsigned short, unsigned char, bool, signed char, bool) (attack.cpp:1354).
1353	in attack.cpp

#-- Leak: counted 419x / total Size: 9637
0x80b35a5 is in NPC::Damage(Mob*, int, unsigned short, unsigned char, bool, signed char, bool) (EQNetwork.h:69).
	in EQNetwork.h

The ones that show up in EQNetwork.h are from the APPlayer constructor, they should be getting cleaned up when the ~ deconstructor is called..

-------------------------------------------------------------------------

Not too sure about these..

#-- Leak: counted 1538x / total Size: 12304
0x80fd4c7 is in Parser::LoadScript(int, char const*) (atomicity.h:50).
49	__atomic_add (volatile _Atomic_word* __mem, int __val)
50	{

#-- Leak: counted 1538x / total Size: 12304
0x80fd4f6 is in Parser::LoadScript(int, char const*) (parser.cpp:984).
	in parser.cpp

Not sure how this code works but..

	EventList* event1 = new EventList;
	Events * NewEventList = new Events;
	while (file && !file.eof())
	{
		getline(file,line);
		string::iterator iterator = line.begin();
		while (*iterator)
		{
			if (iterator[0] == '/' && iterator[1] == '/') break;
			if (!ignore && *iterator == '/' && iterator[1] == '*') { ignore++; iterator++; iterator++; }
			if (*iterator == '*' && iterator[1] == '/') { ignore--; iterator++; iterator++; }
			if (!ignore && (strchr(charIn,*iterator) || quote || paren))
				buffer+=*iterator;
			if (!ignore)
			{
			if (*iterator == '{')
			{
				bracket++;
				if (bracket == 1)
				{
					event1 = new EventList;
					NewEventList->npcid = npcid;
					buffer.replace(buffer.length()-1,buffer.length(),"");
					event1->event = buffer;
					buffer="";
				}
			}

I see event1 is being new'd twice, not sure why it needs to be new'd again if bracket==1 . I think this is most likely a typo, why create a new over the same variable name ? Im pretty sure this is going to discard the memory address of the 1st one, and leak it, but im not 100% sure.

Also, there are no corresponding deletes to the list new's , probably need to be added to the deconstructor also

[kathgar]

All of those death/damage ones should be fixed, loot one is fixed.
With the parser ones.. i'm not sure parser ever cleans up after itself. It's a lot of code to go through but I got the impression that even if that zone is unbooted things will still be loaded.. obviously as 'bad thing'(tm).

Thank you all for your help.

[arkaria]

Has public CVS been updated? Looking at the mod dates on the files there are only 3 that have changed in the past 7 days:
zone.leak
splintreport.txt
splint.sh

[Trumpcard]

Yes, I pushed it out both last night and this morning. I just removed zone.leak and the splint stuff, that was an accidental checkin, along with world.386 and world.pent.

I think that LE has started updating CVS at the same time he makes changes to the dev only CVS, and that might be causing conflicts in my jobs..

I'll take a look tonight, I might have to rewrite the CVS jobs... They were originally written with the idea that I'd be the only one putting updates in CVS , so the method I used was very simple and primitive, and probably prone to problems when other people put changes directly into CVS.

[arkaria]

I think I'm missing something here.

So CVS has been updated? If so why are all the files dated Nov 11? And the .leak file is also still there.

[Trumpcard]

If you delete your soruce directories, and pull everything down fresh, it won't be there...

assuming you use anonymous 'cvs checkout' to pull code code down as opposed to that junky web interface.

[bobzub]

Lets see...

I ran the leakcheck script on a single instance of zone, which I
compiled with the -g flag. For that zone, I ran a static area,
which was gfaydark. I asked people on the server to zone in
and out, but I have no idea what they did since I asked via
console. At that point I had to leave, and I was away for maybe
an hour. So it ran for about an hour.

I will grab CVS from today and compile it. If all goes well
I will run leakcheck on a zone again, and try to get people
into the zone to help out.

Thanks,

-bobzub

[bobzub]

Sorry to ask about his, but I just did a fresh pull from cvs after
moving my eqemu dir to another location. I was looking in
common/version.h, and notice DR5 still in it. Is this correct?


-bobzub

[arkaria]

Yeah same thing here. I always pull a fresh copy from CVS via the command line and all the files are from Nov 11th. Public CVS has not been updated since Pre 5.0 release.