Strange memory leak in Visual C++ 2012 Update 2 - visual-c++

I don't known why the code below is produce memory leak
XTL::CManagedInternetHandle hRemoteFile;
XTL::CUrlExPtr pFinalUrl;
if (dwServiceType == INTERNET_SERVICE_HTTP)
{
throw CWindowsInternetException(url, E_FAIL, L"Unable to get final URL.");
But, when I move the throw to above, Like this
XTL::CManagedInternetHandle hRemoteFile;
XTL::CUrlExPtr pFinalUrl;
throw CWindowsInternetException(url, E_FAIL, L"Unable to get final URL.");
if (dwServiceType == INTERNET_SERVICE_HTTP)
{
no memory leak occurred.

Solved. The memory leak is occurred in the method caller. I still don't known why memory leak report work only on the first code. It should work on both. Maybe it is a bug of VC++.

Related

Node.js search for memory leak

I am trying to get rid of memory leak but my understanding of things is pretty low in this area and I have nobody to ask for help expect you guys. My script is killing server RAM and I can't figure out what is wrong with my approach.
I have this function:
function getPages(params){
gmail.users.messages.list(params, (err, resp)=>{
for (var message of resp.messages) {
message['ownerEmail'] = currentUser;
getMessage(message); // this does something with it later
var message = null;
}
if(resp.nextPageToken){
params.pageToken = resp.nextPageToken;
getPages(params);
} else {
// resolve end here...
}
})//gmail.users.messages.list
}//fetchPages
getPages(params);
Basically it gets messages from the API and should do something with it afterwards. It will execute itself as long as there is more data to fetch. (as long as nextPageToken exists in response).
Now I ran this command:
$ free -lm
total used free shared buff/cache available
Mem: 11935 1808 7643 401 2483 9368
Low: 11935 4291 7643
High: 0 0 0
Swap: 6062 0 6062
As script is running buff/cache is constantly increasing.
What is the buff/cache thing actually and how is it related to my Node script?
How do I manage what is buffered/cached and how do I kill/clear such stuff?
How do I optimize function above to forget everything that is already processed?
How do I make sure that script takes absolutely zero resources once it is finished? (I even tried process.exit at the end of the script)
How do I debug and monitor RAM usage from my Node.js script?
I don't think that there is a memory leak. I think that you are in an infinite loop with the recursion. The gmail.users.messages returns the response with the resp.nextPageToken being present (I suppose) and then you are calling the getPages(params); again. Can you put a console.log just before the getPages(params); function call? Something like that:
if (resp.nextPageToken) {
params.pageToken = resp.nextPageToken;
console.log('token', params.pageToken)
getPages(params);
}
and check how many times do you print this and if you ever get out of the recursion. Also, why do you set the message to null into the iteration? There is a redefinition of the variable.
You can use N|Solid (its free for development), you'll launch your app inside its wrapper. Its quite easy to use and it allows you to make full profile where leak occurs.
You can also do it manually with built in debugger, check memory consumption at each step.
Just to answer one of questions within the post:
How do I make sure that script takes absolutely zero resources once it
is finished? (I even tried process.exit at the end of the script)
There has been misunderstanding:
http://www.linuxatemyram.com/
Don't Panic! Your ram is fine!
What's going on? Linux is borrowing unused memory for disk caching.
This makes it looks like you are low on memory, but you are not!
Everything is fine!

Memory Leak in Express.js with EventSource

I think I am running into a memory leak with an Express app when connecting x number of EventSource clients to it. After connecting the clients and sending them x messages and disconnecting them, my Express app only releases a small amount of the allocated Heap/RSS.
To confirm this I saved a Heapdump when starting the server and one after connecting 7,000 clients to it and sending x messages to each client. I waited for a while to give the GC a chance to clean up before taking the heap snapshot.
To compare these heap snapshots I loaded them in the Chrome Developer Tools Profile view and chose the "Comparison" mode.
My questions are:
1) How to interpret these numbers?
(For reference see the attached heap snapshot screenshot.)
2) For instance it looks like that the Socket objects doesn't almost free any objects at all, is that correct?
3) Can you give me more tips to investigate the problem?
You could be free from memory leak and as a bonus avoid the garbage collector.
All you got to do is object polling.
You could do something like
var clientsPool = new Array(1000);
var clientsConnected = [];
When a new client connects, you do
var newClient = clientsPool.pop();
//set your props here
clientsConnected.push(newClient);
That's an awesome way to avoid the Garbage Collector and prevent memory leak. Sure, there's a little more work to it and you will have to manage that carefully but it's totally worth for performance.
There's an awesome talk about it, here you go
https://www.youtube.com/watch?v=RWmzxyMf2cE
As to my Comment...
Javascript can't clear up a section of memory should anything be pointing at it about 2 years ago some one found an exploit and it was quickly closed like that and it works like this
var someData = ["THIS IS SOME DATA SAY IT WAS THE SIZE OF A SMALL APPLICATION"];
var somePointer = someData[0];
delete someData;
they then injected an application into somePointer as it was a reference to a memory location when there was no data now. hey presto you injected memory.
So if there is a reference like above somePointer = someData[0]; you cant free the memory until you delete someData so you have to remove all references to anything you want cleaning in your case ALL_CLIENTS.push(this); on line 64 is making your system memory accessible through ALL_CLIENTS, so what you can do is
Line 157
_.each(ALL_CLIENTS, function(client, i) {
var u; // holds a undefined value (null, empty, nothing)
client.close();
//delete ALL_CLIENTS[i];
ALL_CLIENTS[i] = u;
ALL_CLIENTS.unused++;
});
On another note this is not a memory leak a memory leak is say you had this server you close it if the memory did not free up after you exited it then you have a memory leak if it does clean the memory behind it's self it's not a leak it's just poor memory management
Thanks to #Magus for pointing out that delete is not the best thing you could use however i would never recommend that you implement a limiting structure but you could try
Line 27:
ALL_CLIENTS.unused = 0;
Line 64:
var u;
if(ALL_CLIENTS.unused > 0){
for(var i = 0; i < ALL_CLIENTS.length; i++){
if(ALL_CLIENTS[i] == u){
ALL_CLIENTS[i] = this;
ALL_CLIENTS.unused--;
i = ALL_CLIENTS.length;
}
}
}else{
ALL_CLIENTS.push(this);
}

Copy Constructor for MyString causes HEAP error. Only Gives Error in Debug Mode

So, I've never experienced this before. Normally when I get an error, it always triggers a breakpoint. However, this time when I build the solution and run it without debugging (ctrl+F5), it gives me no error and runs correctly. But when I try debugging it (F5), it gives me this error:
HEAP[MyString.exe]: HEAP: Free Heap block 294bd8 modified at 294c00 after it was freed
Windows has triggered a breakpoint in MyString.exe.
This may be due to a corruption of the heap, which indicates a bug in MyString.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while MyString.exe has focus.
The output window may have more diagnostic information.
This assignment is due tonight, so I'd appreciate any quick help.
My code is here:
https://gist.github.com/anonymous/8d84b21be6d1f4bc18bf
I've narrowed the problem down in the main to line 18 in main.cpp ( c = a + b; ) The concatenation succeeds, but then when it is to be copied into c, the error message occurs at line 56 in MyString.cpp ( pData = new char[length + 1]; ).
The kicker is I haven't had a problem with this line of code until I tried overloading the operator>>. I've since scrapped that code for the sake of trying to debug this.
Again, any help would be appreciated!
Let's go through line 18:
1. In line 17 you create string c with dynamically allocated memory inside.
2. You make assignment: c = a + b:
2.1. Operator+ creates LOCAL object 'cat'.
2.2. cat's memory is allocated dynamically.
2.3. cat becomes concatenation of two given strings.
2.4. Operator+ exits. cat is LOCAL object and it's being destroyed.
2.4.1. cat is being destroyed. cat's destructor runs.
2.4.2. destructor deletes pData;
2.4.3. After delete you make *pData = NULL. //ERROR - should be pData = NULL (1)
2.5. c is initialized with result of operator+.
2.6. operator= calls copy().
2.7. copy() allocates new memory without checking the current one. //ERROR - memory leak (2)
(1)
pData is char*. In destructor we have: delete[] pData (deletes memory) and then *pData = NULL.
Because pData is a pointer, *pData is same as pData[0]. So you write to already freed memory. This is the cause of your error.
(2)
Additional problem. Copy() overwrites current memory without checking. Should be:
copy()
{
if(this->pData)
{
delete this->pData;
}
//now allocate new buffer and copy
}
Also, when dealing with raw bytes (chars), you don't want to use new() and delete(), but malloc() and free() instead. In this case, in functions like copy(), instead of calling delete() and then new(), you would simply use realloc().
EDIT:
One more thing: errors caused by heap damage usually occur during debugging. In release binary, this will simply overwrite some freed (and maybe already used by someone else) memory. That's why debugging is so important when playing with memory in C++.

Getting an image from a sample buffer

I am trying to capture a screen shot on the ipad while the camera is on. My code looks exactly like the AVCaptureFrames from the Xamarin MonoTouch sample:
For some reason, though, I keep getting an Invalid Handler Exception. I have looked at other questions similar to mine, such as:
CGBitmapContext in MonoTouch throws invalid handle exception and "Invalid Handle" Create CGBitmapContext
But their solutions aren't solving my similar problem. My issue doesn't stem from a sending in null or because my memory is too large. I'm not sending in a null value and I checked my memory usage through the xcode allocations instrument and my memory usage doesn't explode; it only adds 400KB at the most.

debugging a strange error when new is called

I have a program that when run compiled with Microsoft Visual C++ 2008 Express crashes on the line
comparison_vectors = new vec_element[(rbfnetparams->comparison_vector_length)+1];
with the error Unhandled exception at 0x7c93426d in myprog.exe: 0xC0000005: Access violation reading location 0x00000000
rbfnetparams->comparison_vector_length evaluates to 4 (should do and checked in the debugger), and the thing still crashes here when I change the line as a test to:
comparison_vectors = new vec_element[5];
vec_element is a structure with several ints, doubles and a few bools, but no methods or constructor. The thing runs if I replace new with malloc, but then crashes on another new elsewhere. It does not crash every time this line is run, only sometimes, but seems to do so after the same number of iterations of this line each time. Memory usage is only 10MB at this point in the program.
This gets stranger as the same program DOES compile and run under gcc on Solaris, which usually shows up far more errors than Windows does.
Any help would be appreciated, as I am at a loss as to how to debug this one.
Access violation reading location 0x00000000 means "you dereferenced a NULL pointer." It looks like once in a while rbfnetparams is NULL when you reach this line, and thus you get the error.
I can't explain why comparison_vectors = new vec_element[5]; crashes. Is it the same error message?
Check if rbfnetparams is NULL before the line, and see if it gets hit (or add a conditional break point). Then decide if the fact that rbfnetparams is NULL is a symptom of a bigger bug somewhere else.
Dereferencing a NULL pointer is undefined. It's possible that the Solaris compiler does an optimization that masks the bug. That's allowed by the Standard (read the whole series referenced from that post).

Resources