Dopus using 7GB of RAM

@mojo-chan

Yes a watch pot never boils indeed. Dopus.exe has been as good as gold since the last incident.

Did we have any processes in common?

Let me know if you want me to run any parallel experiments

Okay, it finally happened. Opus is using half a gigabyte of RAM with one window open. Every time I re-start the RDP session the amount of RAM used doubles.

Unfortunately this isn't my minimal test VM, it's my in-use server. It is quite minimal though. The only things installed are drivers, Firefox, Java, Cumulus, PS3 Media Server, Microsoft Security Essentials (real-time scanning disabled), Dropbox and uTorrent. No codecs installed. The system is running, for now I can do more diagnostics but I probably only have one or two more RDP sessions before it eats all my RAM.

Here is the VMMap dump: mega.co.nz/#!tIwmnQKS!cKce6CZUi ... X_D2GnIfm4

It looks like the bulk of the memory use is the heap.

Sorry, forgot to add Classic Start Menu is installed. It wasn't installed in the VM though, so I think we can rule that out along with all the other stuff.

As for triggers I'd say either a heavy uTorrent session or perhaps closing the RDP session with an Opus window open displaying a drive that subsequently went into power saving mode (spun down). Normally Opus uses about 15MB of RAM and I noticed it climbing earlier today. The system has been up for about four days (rebooted to do some Windows updates).

DOpus goes to 100% CPU for about 20 seconds, doubles it's RAM usage and then settles down every time I open RDP. I need to kill it soon so I can use the machine.

Is everyone taking an early holiday this year? :slight_smile:

If reconnecting the RDP session is a reliable trigger then we're definitely getting somewhere.

Please generate a VMMap trace (different to the VMMap snapshot posted above).

Using VMMap on the remote machine (where the leak is), starting the trace, then disconnect and reconnect the RDP session with the trace still running. If the leak is triggered while the trace is running then the trace should then tell us which EXE or DLL allocated the memory (and hopefully more).

Also, please let us know the details of the RDP set up (e.g. which resources the RDP client is configured to share between the two machines, and other RDP client settings; also the versions of Windows on each machine) so we can try recreating a similar setup.

It may also be worth checking if the problem depends on what is in the clipboard when you make the RDP connection. e.g. If there is a small amount of text in the clipboard, does it still happen? Or does it only happen if files are in the clipboard, or similar?

Thanks Leo, I have started a trace and will report back when it happens again.

I will get exact versions of the RDP client when I get home. It is Windows 7 x64 on both sides, up to date with patches but not the optional RDP V8 (from Windows 8) as I didn't want to change anything until the problem is found and preferably reproducible.

Well, VMMap crashed, so that's a good start. I'll try it again. I closed the RDP session and when I came back a while later it wasn't there, although Opus was running. RDP is V6.3.9600.

VMMap seems to crash every time. It works for a while, I go away for a few hours and come back to find it's just gone with no error message or explanation.

VMMap crashing, been there, done that:

Dopus using 7GB of RAM

Its a terrible tool.

Yeah, so we are kind of screwed because if you are having the same experience there is pretty much no chance I am going to get it to run for a week or two.

VMMap uses a lot of memory while tracing. (It has to, it's recording a lot of information.) So it will run out of memory and crash if you leave it running for more than a short time.

If it doesn't survive long enough to disconnect and reconnect to the RDP session then we are in trouble, though. :frowning:

FWIW, I tried lots of RDP re-connections earlier and Opus's memory usage remained stable. That was with:

[ul][li]Windows 7 x86 to Windows 7 x64.[/li]
[li]Drives and Clipboard being shared (no printer, though).[/li]
[li]Themes enabled, but Desktop Composition disabled.[/li]
[li]Everything else set to the settings you get if you choose the highest bandwidth mode.[/li]
[li]Over gigabit ethernet.[/li][/ul]

I don't think it is the RDP connect/disconnect specifically that causes it. All I said was that when something breaks and it starts chewing up memory it allocates twice as much every time you start an RDP session.

It seems that there is no way to diagnose this problem. Well, the developers could do it with their IDE/debugger, but they can't reproduce it. Could you make a test binary that dumps out debug information on demand?

Debug information about what, exactly?

I don't know what compilers/frameworks/debuggers you use but often there is a way to dump a stack trace or list of memory allocations. I'm an embedded programmer so I'm not all that family with desktop stuff but IIRC there is run-time performance monitoring stuff for the Microsoft C++ compiler... Yeah, CRT Debug I think, monitors all heap allocations. There is still for GCC as well, of course. VMMap can't be the only memory debugger you can use.

A list of memory allocations won't say anything about which component or piece of code allocated them, which is what we need to know. The only place Windows records which component allocated memory is with some memory allocations made by drivers, which are unlikely to apply here.

that is not entirely true. _CrtDumpMemoryLeaks will dump first few bytes of each leaked object which will hold the address of vtable pointer which is unique for every class with virtual members you have.

That is assuming the large memory allocations are C++ objects, and objects with virtual functions, and that the vpointer can be interpreted just from the number (all possible but unlikely) and that, if all are true, it's an Opus object and not something from Windows, a shell extension, or another component (where we'd be unable to interpret the pointer even if the number really was a pointer).

It's possible to view those bytes using VMMap and other debugging tools anyway. We don't need to build a special exe to enable it. If you can reproduce the problem and spot a pattern in the memory, let us know. I think it's unlikely though.

Focusing on finding a reliable way to reproduce the problem(s) is probably better, if we can't get a VMMap trace to work. (I say problems because I am still not convinced the few reports here are all the same thing. Lots of things can cause memory leaks and the reports have very different takes on what causes it for them.)

Have just had DOpus complaining about memory usage. Remember reading this thread about memory usage.
Was not doing anything different than I have done before.
Programs open
Dopus 11.4
IE11
Microsoft Photo Gallery
Nero 14 (burning some disks)
Epson print CD (printing labels for disks)
Google Chrome [Chekink version number}
Shut down Chrome and Epson Print Cd as finished with them
Got message again from Dopus
Shut down IE11 Microsoft Photo Gallery as finished using them.
Started Resource Monitor and found that it was DOpus that was using the memory
Started VMMap
Have attached a screen capture of VMMap.
Hope this will Help


That screenshot only really tells us that a lot of memory has been allocated by dopus.exe. It doesn't tell us which component allocated it.

Please follow the steps in How to find components causing memory leaks, and please start a new thread if you get results from those steps.

A description of what was happening when the leak occurred is also important. It might not be anything unusual to you, but we don't know what your usual is. :slight_smile: The types of files being looked at around the time the leak happened are often important. As are things like right-clicking files, or changing to folders you don't often go into, both of which can trigger shell extensions and video codecs, which are almost always the causes of memory leaks. If a viewer is open or was recently used, that's also worth mentioning, along with the file types involved.

I've locked this thread as it has become a generic place to report (almost certainly unrelated) memory leaks, and has so much discussion that people are not finding the important parts & not noticing/following the guide.

Remember that memory leaks can be caused by a lot of different things, most of them 3rd party components which are loaded into Opus. You need to follow the guide I linked to work out which component is causing the leak, and post that information to the forum.