Virtual memory Problem [modified]
-
Hi All, i have a vc++client and i'm using com components having business logic. Problem: i'll not close the client application. but the virtual memory accupied by the process is not freed. when it reaches maximum of virtual memory client application crashes. please give me the solution what to do avoid crashing. Thanks in Advance. Prashanth. -- modified at 2:58 Friday 2nd February, 2007
-
Hi All, i have a vc++client and i'm using com components having business logic. Problem: i'll not close the client application. but the virtual memory accupied by the process is not freed. when it reaches maximum of virtual memory client application crashes. please give me the solution what to do avoid crashing. Thanks in Advance. Prashanth. -- modified at 2:58 Friday 2nd February, 2007
voorugonda prashanth wrote:
the virtual memory accupied by the process is not freed.
You are experiencing memory leaks. Are you using
new(or, worse,malloc) withoutdelete(orfree)? Are you properly usingdelete[]when deleting an array? Are your COM-Components OK and properly releasing when no longer used? Are you sure you are releasing them?
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
Hi All, i have a vc++client and i'm using com components having business logic. Problem: i'll not close the client application. but the virtual memory accupied by the process is not freed. when it reaches maximum of virtual memory client application crashes. please give me the solution what to do avoid crashing. Thanks in Advance. Prashanth. -- modified at 2:58 Friday 2nd February, 2007
voorugonda prashanth wrote:
when it reaches maximum of virtual memory client application crashes.
i believe we cannot be much use for you as you urself have to debug the application to find cause of memory leaks
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers, Alok Gupta VC Forum Q&A :- I/ IV Support CRY- Child Relief and you
-
voorugonda prashanth wrote:
the virtual memory accupied by the process is not freed.
You are experiencing memory leaks. Are you using
new(or, worse,malloc) withoutdelete(orfree)? Are you properly usingdelete[]when deleting an array? Are your COM-Components OK and properly releasing when no longer used? Are you sure you are releasing them?
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
jhwurmbach wrote:
Are you using new (or, worse, malloc)
Why would using
mallocbe wrose than usingnew? What do you think new is calling internally? -
jhwurmbach wrote:
Are you using new (or, worse, malloc)
Why would using
mallocbe wrose than usingnew? What do you think new is calling internally?WalderMort wrote:
Why would using malloc be wrose than using new?
malloc is very fine - in C-code. With C++ and objects, you better use
new.WalderMort wrote:
What do you think new is calling internally?
How could I know? Why would I care? Thats an implementation detail that can (and will!) change. I have even seen an heap manager to be written from scratch.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
jhwurmbach wrote:
Are you using new (or, worse, malloc)
Why would using
mallocbe wrose than usingnew? What do you think new is calling internally?A huge difference is that for an object the constructor is not guaranteed to be called when using
::malloc(), but it's guaranteed to be called when usingnew. The same goes for::free()anddelete. Read Stroustrup's FAQ for more info: clickety[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
-
WalderMort wrote:
Why would using malloc be wrose than using new?
malloc is very fine - in C-code. With C++ and objects, you better use
new.WalderMort wrote:
What do you think new is calling internally?
How could I know? Why would I care? Thats an implementation detail that can (and will!) change. I have even seen an heap manager to be written from scratch.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
hi, i'm not using malloc or new in my application. i'm using only vectors of class objects allocated on stack itself. i dont see any problem with vectors of class objects allocating on stack. steps: 1) client application talks to the component 2) which internally talks DBHandler component which connects to SQL Server and returns the result back. 3) the result i'm storing in vectors for processing. 4) return back to the client. i'm not able get what exactly the problem is??
-
hi, i'm not using malloc or new in my application. i'm using only vectors of class objects allocated on stack itself. i dont see any problem with vectors of class objects allocating on stack. steps: 1) client application talks to the component 2) which internally talks DBHandler component which connects to SQL Server and returns the result back. 3) the result i'm storing in vectors for processing. 4) return back to the client. i'm not able get what exactly the problem is??
voorugonda prashanth wrote:
dont see any problem with vectors of class objects allocating on stack.
Only when these objects are correctly copy-construcable. All objects in STL vectors will be copied when needed, and the old instances deleted. Some object may not properly delete their allocated resources when simply deleted and need to have a special deletion routine been called. Poor design, that. You say that you store results of an SQL-transaction. When this result does not hold a link to the SQL-connection and is simply data stored in members and not
newed, I am also not able to get where the problem is. -- modified at 9:08 Friday 2nd February, 2007 typo
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
A huge difference is that for an object the constructor is not guaranteed to be called when using
::malloc(), but it's guaranteed to be called when usingnew. The same goes for::free()anddelete. Read Stroustrup's FAQ for more info: clickety[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
I know what the difference is between the two, but I would like to know why he thinks using malloc is worse than using new. Granted, using new has become the standard in c++ code, but there are instances where using malloc has proved to be better, take the resizing of dynamic arrays for example or needing to allocatate an instance without calling the c'tor ( not that I can think of a valid reason for doing this ).
-
I know what the difference is between the two, but I would like to know why he thinks using malloc is worse than using new. Granted, using new has become the standard in c++ code, but there are instances where using malloc has proved to be better, take the resizing of dynamic arrays for example or needing to allocatate an instance without calling the c'tor ( not that I can think of a valid reason for doing this ).
WalderMort wrote:
but there are instances where using malloc has proved to be better
Sorry, WalderMort, I don't know what you're referring to by this statement. If you follow the link I provided in my previous post and scroll up a few lines, you will find this:
Stroustrup wrote:
There is no performance difference between malloc() and new when you take initialization into account.
In my humble opinion, if you find yourself in a situation where you think you benefit from the use of
::malloc()in C++, you're probably not using the language in the way Stroustrup intended. This is also how I interpret his statement a little bit further down:Stroustrup wrote:
If you feel the need for realloc() - and many do - then consider using a standard library vector.
WalderMort wrote:
needing to allocatate an instance without calling the c'tor
I cannot possibly think that I will find myself in a situation where I actually want to use uninitalized data, the compiler would also complain about it. If you want to create a copy of an existing object, you don't use
::memcpy():omg: but you would rather use the copy constructor or the assignment operator. But that may be just me...:-> ...but I think not...
"It's supposed to be hard, otherwise anybody could do it!" - selfquote