Server Help

[CypherJF]

Using MervBot b45/b46 - is there any way to come up w/ an effective way of determining that there are no memory leaks occuring within a specific plugin? I'm pretty confident I have deleting allocated memory, but would like to put my mind to ease over it. MMaverick said there used to be a way? Thanks in advance.
_________________
Performance is often the art of cheating carefully. - James Gosling

[Solo Ace]

Try using this (this code came straight from MSDN Library), it works fine for me heh.

Code: Show/Hide // Where your DLL is loaded, call these:     _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );     _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );     _CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );     _CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT );     _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );     _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT ); // Then where you want to check for a memory leak, see if there are memory leaks and dump results into the console:     _CrtDumpMemoryLeaks( );

Taken from MSDN's _CrtDumpMemoryLeaks.

Hope that helps, good luck.

[CypherJF]

Thanks now to interpret the results:

[CypherJF]

Sorry for the double post, but when I did the MervCore - w/ debug mode - there were a ton of memory leak objects detected. :shrug:

[Cyan~Fire]

Look for anywhere where you could be allocating those sizes. That's really the only way to do it.
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Mr Ekted]

Not so.
_________________
4,691 irradiated haggis!

[CypherJF]

I take it that there is no possible way of figuring it out - without checking everything by hand then eh?

[Mr Ekted]

There are lots of ways. All the information you need is in your dump.

[CypherJF]

Way to be cryptic Mr Ekted - care to elaborate on HOW I could go about doing this? *continues to read on the Heap State Reporting Functions/Info on MSDN*

[Solo Ace]

Whenever you allocated a variable you should let it output some information about the allocation.

Use this macro every time after allocation.

Code: Show/Hide #define DEBUG_NEW(x) printf("allocation: %s %d 0x%p\n", __FILE__, __LINE__, x)

By doing this you can "trace" the leaking variable back by using the address the dump gave you.

I wouldn't know any other or better ways, so, Ekted, giving some more help would be appreciated.

[CypherJF]

Just some cliff-notes:
{#} - this allocation request number is enclosed in curly brackets (for example, “{36}”).

And -- New objects are filled with 0xCD when they are allocated.

msdn

msdn2

[Mr Ekted]

1. You have the length and content of the leaked memory. So you are looking for allocations of 12 and 88 bytes. Find all your allocations and look at how big they are.

2. You have the contents. What structures that you allocate could contain the data "F0 0E E7 00" or "00 CD CD CD"?

3. You have the addresses. If you run the EXE under exactly the same circumstance with no random elements, all of the allocations will be the same addresses.

[CypherJF]

Well, I did tested that macro that Solo gave - and the memory addresses provided do not match any of the allocations that I perform. I'm going to start assuming it has to do w/ a leak in the core?

the only structures that I 'new' up are

Code: Show/Hide struct PlayerTag {    Player *p;    char name[20];    int index;    int data; }; struct OffenseTag {    Player *killer;    Player *killed;    int time;    int id; };

OffenseTag would be 12 byte's - right?

[Mr Ekted]

PlayerTag is 32. OffenseTag is 16.

I assumed you had run the core without your DLL first. If it's the core, you will get that same dump.

[CypherJF]

Ya, I didn't post that run of a clean core run w/o plugin. I was looking at the src code more closely the one offset is the

botInfo *bot;
...
bot = new botInfo(event.handle);
botlist.append(bot);


Anyways, the botlist is never cleared out or delete the dynamically allocated memory - Catid told me he had that intentionally in there because it was a fix to something, if he recalled correctly (I can see Ekted 'cringe' at that ).

So that's technically 1 allocation that isn't cleared which I could find - to find a fix - ... is another question. But thanks everyone for the help.

[Mr Ekted]

If it's always just the 2 blocks no matter how long you run, then you are fine. The process isn't leaking memory over time.

[CypherJF]

But it is my understanding though that the dynamically non-released memory will never be allowed to be claimed by the heap manager until a system reboot - is that correct?

Like Catid said, it's fine if it leaks - but it's only bad if you're always unloading and reloading plugins...

But really, there should be no memory leaks in an application - if at all possible.

[Bak]

I believe it's freed when the process terminates, because each process has it's own virtual memory that's 4 gigs big
_________________
SubSpace Discretion: A Third Generation SubSpace Client

[CypherJF]

I've read that before, but I wonder how that comes into play when my professors were teaching the class what I had mentioned in my other post. Was this the case for the older programs/OS'?

[Cyan~Fire]

Windows is supposed to clean up every program's heap, but it doesn't always do the best job of it, which is why I always manually free everything.

[Mr Ekted]

Everything specifically allocated on any heap is freed when the process is terminated. This is also true of window handles, resource handles (pens, brushes, fonts, etc), open files/pipes/mutexes/etc. The only thing I can see being an OS-level leak would be handles into driver objects with a bad driver (not cleaning up correctly), but the user-level has no control over this.

[Cyan~Fire]

Well, it's only one more line of code in your app, so I'd say it's a case when "better safe than sorry" is actually true.

[Mr Ekted]

I'm not saying "don't worry about freeing stuff." By all means write clean code. But if the leak is in the core, and you don't feel like debugging someone else's problem, AND it's not a recurrring leak, then it's not as a big a deal.

[CypherJF]

Got'cha, thanks everyone.

[Cyan~Fire]

Ok. There are no leaks in the core. (Or at least none that the CRT detected.)