Well, if you're object is a mfc object, which is derived from CObject, then MFC provides an iteration mechanism to iterate through your objects. You can use it to track the count of your objects in heap, you can dump selective objects... etc... etc... Well, how can you do it?

Use the api - AfxDoForAllObjects(). While calling we've to pass a function pointer of expected syntax, and for each CObject derived object in heap, the function will be called. See the sample to iterate all CDynLinkLibrary objects and to find its count.

// This function will be called as callback
// from AfxDoForAllObjects.
void DoForAllObjects(CObject* pObject, void* pContext)
{
    // Here context is the pointer to count variable.
    int* pCount = (int*) pContext;

    // Check whether the object is of type CDynLinkLibrary
    if( dynamic_cast<CDynLinkLibrary*>( pObject))
    {
        // Increment count.
        ++(*pCount);
    }

}

// Iterate objects.
void CDialogDlg::Iterate()
{
    // Iterate all CObject instances and get the
    // count of instances of CDynLinkLibrary objects.
    int DynLinkLibCount = 0;
    AfxDoForAllObjects( DoForAllObjects, &DynLinkLibCount );

}

You can utilize this for finding memory leaks, to find the count of instances of a particular class, you can dump objects of particular class, etc...

Well, one thing to remember - its only available in debug build. So take care! ;)

Targeted Audience - Intermediate.

This and this point out issues on memory limits with Excel.

I am doing pretty dodgy stuff like calling python scripts from VBA, among other things. Python is much, much nicer for parsing text files however...

You've to enable memory leak tracking by defining constant - _CRTDBG_MAP_ALLOC and then call - _CrtDumpMemoryLeaks(). Now the leaks will be dumped to the Visual Studio output window. See the following code snippet.

// Declare this in header.
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
...
void DetectLeaks()
{
    // Create some leaks.
    CString* pString = new CString;
    BYTE* pBuffer = new BYTE[100];

    // Dump memory leaks to output window.
    _CrtDumpMemoryLeaks();
}

When you call _CrtDumpMemoryLeaks() the memory leak information will be dumped to the output window. For instance, see the dump for memory leaks that we've made in DetectLeaks().

Detected memory leaks!
Dumping objects ->
C:\Jijo\Studies\VC++\MFC\RabbitDlg\RabbitDlgDlg.cpp(183) : {194} normal block at 0x00294990, 100 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
C:\Jijo\Studies\VC++\MFC\RabbitDlg\RabbitDlgDlg.cpp(182) : {193} normal block at 0x00293B20, 4 bytes long.
 Data: <   _> 14 FB 8C 5F
...
Object dump complete.

The filename and line number of leak will be present in the dump. So easy, nah?

While creating your MFC applications, did you ever noticed a code block as follows in your files?

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

This is for debug information. By using this information, the _CrtDumpMemoryLeaks() keep track of the filename. If you comment out this, the filename will not be present in the dump which will make our task difficult. So never remove those line. I swear, they are really important! ;)

Targeted Audience - Intermediate

This affects Backup Exec 11d rev 7170.0 with no hotfixes or service packs and with service pack 2 with all current hotfixes (as of 21st April, 2008). So, I assume all minor versions between the base and the latest are affected.

The problem relates to a remote server - namely a server with a remote agent that is running on a Windows 2003 R2 Server 64bit with service pack 2. Also installed on this server is Exchange Server 2007 with service pack 1. The version of the agent is 7170.0 - the latest version at the time of writing this post.

There's one more thing. The backup is being encrypted. When I disable the encryption the problem doesn't reoccur. So it must have something to do with that.

In one case I saw the process beremote.exe holding 1.5GB of virtual memory, even though there wasn't a backup running. Of course, this takes resources away from the system and services like the Exchange 2007 Information Store gets a wee bit upset about this.

In another example, with the same setup (Windows R2 sp2 with Ex2k7 with SP1), beremote was consuming 6.8GB of virtual memory. See image below.

So, what to do? Well here's a technote from Symantec: http://seer.entsupport.symantec.com/docs/289695.htm

Here's an extract from the article:

Details:
Each time a GRT backup of an Exchange server is performed, the memory used by the Backup Exec Remote Agent for Windows Servers ( RAWS ) process, beremote.exe, may increase. In this situation, the memory used by beremote.exe does not drop back down after backup but continues to rise with each mailbox backup performed.

Note, I have other systems set up in a similar way that are not affected by this problem. The only difference is that in these cases the backups are not being encrypted.

Symantec don't offer a fix for this problem at the moment, just a workaround. The workaround is to restart the backup exec agent. This could be done via a scheduled task calling a batch file. Basically, the offered solution is a fudge, not a fix.

It is, however, very important to encrypt your backups, so turning encryption off is not the solution either - this just avoids the problem.

I don't know if Backup Exec v12 is affected by this issue. I've not done enough testing in this version yet.

Symantec Tech Support can only offer the fudge and there's no hint of a fix being released.

For now, the only way forward is to restart the agent when you're sure the backup process is not in use. So here's an idea, as an interim solution. Configure the backup job so that it runs a batch file that will restart the backup agent service. To do this, under Job Settings | Pre/Post commands, call a batch file that restarts the remote agent on the remote server. Tip, use the 'SC.EXE' command in the batch file. Details on the command are here. Here's an example of the command in full:

sc \\REMOTE_SERV stop BackupExecAgentAccelerator & timeout /T 30 && sc \\REMOTE_SERV start BackupExecAgentAccelerator

(there's no carriage return within the command, only at the end)

In the example above, change 'REMOTE_SERV' with the name of your remote server that is affected by this problem. Note, the '/T 30' part of the command relates to the timeout required between sending the stop command and sending the start command. 30 seconds seems to work okay for me. You may want to increase this timeout if the service doesn't start (because it hasn't yet finished the stop command).

Hope this helps. Let me know if you've come across this problem.

BEBlue

Creo que tengo unas 15 tabs abiertas, y un historial bastante grande de navegación en el día. Condenado firefox, hasta ya cuesta que cambie de pestaña.

¿Y a ustedes, qué tanta memoria les consume memoria el navegador?

Etiquetas: firefox, software, memory leaks, navegadores, sucks

*Update: This is a old post that i wrote when Firefox 3 was still in early days of development and before the performance improvements were done.*

I switched from IE to Firefox 1.5 because of its amazing features like tabs, better session saver, add-ons and most of all its developer friendly tools like FireBug which to me came as a breather for web-development. And needless to say i never missed IE.

But then, as i became addicted to the tabbed browsing, like many others even i cultivated a bad habit of opening the links that i would like to read and come back later when i had time. so usually i had i atleast 15-20 tabs in each window and atleast 2-3 windows open. see it was just convenience...!!

Memory leaks in Firefox and moving onto Opera

But because of my bad habit of having so many tabs open, the memory hogging in Firefox was *ahem* unbearable...and lo...to add to that it also started crashing...and at times i
would restart the Firefox manually when the memory usage was very high and i was hoping that this would be fixed in the future versions, but nothing much happened on those lines and i was looking for some alternative, and then i tried Opera (without the ads ;) and it had all the features that i wanted except for the FireBug. But hey..that was okay..when i had to test my sites, i would go to Firefox, but for normal web-browsing, i never missed Firefox, just the way i never missed IE when i switched to Firefox. Opera was just freakin...awesome..!!! and i loved it for the memory footprint that it occupied and it never crashed for me (though, YMMV ;) and to add to that, Opera had lot more features like integrated mail client, newsgroups, saving multiple sessions, needless to say i loved it ;)

Flock

So when i came across the beta release of flock, i was just curious to try it out and my first thoughts were, oh its a replica of Firefox with few more functionalities, primary among those being a integrated access to various social networking sites from its sidebar. well..which was not bad..*ahem* quite good, just like you don't want to open different mail clients for each and every mail account that you have, you would like to have an integrated access to all these social networking sites instead of logging into each one of them. so this integration was quite a welcome feature given the fad for social networking sites. But, hey...is that reason enough for altogether a new browser..? i don't think so..but to be fair, Flock also has other features like Web Clipboard, Blogging client, Media bar, and obviously the sidebar.

But another interesting point that i came across was regarding the memory usage comparison of Flock vs firefox 3.0. well just to double check on this, i fired up all my tabs in Opera in Flock and also in firefox 3.0 and boy Opera beats them all and Firefox crashes as usual :), but though, Flock initially used more memory footprint than Firefox, it never crashed :), which was interesting and i'm just curious what tweaks did Flock guys do to the Firefox engine and why is firefox still not fixing it? i see that firefox 3.0 has loads of features but why are they not fixing this serios issue of frequent crashes..? what will we do with those features when the browser would crash anyway..? well in that sense , kudos to Flock and i hope to see how flock catches up with the new versions of the firefox 3.0 engine. And if they do manage to catch up, then i wouldn't see why people who wants to move to firefox 3.0 should not move to Flock if not my fav browser Opera :)

But hey..i am not going to switch my loyalty from Opera to this new browser for just the side-bar ;)

Opera ROCKS!!!