Memory losse and thread... advice?

Hi!

Recently, I had a crash on my software + a memory loss. I couldn't find out why the software was crashing but after I solved the memory loss problem, everything run fine. So I would like to get your opinion according to your experience:

If I have 10 threads in my application, each of them loosing a lot of 2048 bytes memory (let's say around 20MB for each thread in total, ie 200MB in total for all the threads), after all threads will be destroyed, can a new thread generates a memory exception at any time?

I had this situation, I couldn't find any problem in my software except the memory loss. After solving this memory loss, everything works fine. I already spend a lot of time for this. In your experience, do you think this memory losses in threads that don't exist anymore can explain a crash later in another thread? Or should I keep investigating?

Thank for your advise. If you need more detail for answering, I will give you more.

what is a "memory loss"?

Yes, memory leaks affect a process until terminates, even when threads creating the memory leak have finished.
There're cases when more than one heap manager is used within a process. When a module (lets say a dll) is unloaded, its corresponding heap manager might test its current state, even when other modules still use it. The heap manager might report errors at this stage. Heap managers are thread safe implementations, but if a thread is corrupting a heap, all threads using the same heap might crash on the next allocation / deallocation. Terminating a thread will not fix the problems created in the heap used by that thread.
Local variables are created on the stack, and will not affect other threads... but heap allocations made by a thread, will affect all threads using the same heap (manager)... including threads created after buggy thread terminates.
Still, from your explainations, I didn't understand if your computer was becoming low on resources, and memory leaks do not crash a process until resources are low enough to refuse further allocations. When large blocks of memory are requested, new allocations might be refused after a considerable number of successful allocations, because the heap becomes fragmentated, and no such large block can be found available, even that there's plenty of available memory.
Make sure your implementation is always testing against allocation failures (NULL pointer is usually returned when allocation failed). Look at the callstack at the moment of crash! Find out if it crashes when allocating memory, discarding it, or using it. Each case has different debuging scenarios. Might even be a double delete, or a missing sync between threads using shared variables / objects.
To me, it is very unlikely that a memory leak alone would generate a crash!!!
Regards,

Thank you for your reply. I wanted to make a precision about what I mean by memory loss. To make simple, I did these kind of instructions in a function:

BYTE *up_byte = NULL;
up_byte = new BYTE[2048];
...
up_byte = new BYTE[2048];
...
delete[] up_byte;

This means that I lost 2KB each time I call this function in a thread.
So there is no bad access, just some memory loss. I use "loss" because I am not a native english speaker and I feel that the right term would be "memory leak". But in many place, I found that people use "memory leak" for a bad read/write access. In my case, I don't try to read or write to a place that was not allocated. I just forgot to desallocate memory.

When I get a memory exception, the call stack tells me that it happen when the "new" operator was called. So I guess I couldn't allocate 8MB anymore. But I have 2.5GB of RAM and 1.4GB was used in total so far by all the running processes (from the task manager that I know cannot be trusted so much).

So, should I keep going or search more?

Quote:

---

Originally Posted by madric

I use "loss" because I am not a native english speaker and I feel that the right term would be "memory leak".

---

The correct computer programming term is "memory leak", not "memory loss".

Do not say "memory loss", as that term is used in the medical industry if you have had a head injury, or you have Alzheimer's or some other disease and you do not remember things.

Quote:

---

But in many place, I found that people use "memory leak" for a bad read/write access.

---

I have never seen "memory leak" to mean bad access. Memory leak has always meant where you've allocated memory, and failed to deallocate it.

Quote:

---

So, should I keep going or search more?

---

You should just fix your program to not leak memory.

Regards,

Paul McKenzie

Thank for the english lesson!
Anyway, I did fix the memory leak and it now works fine. My application does not crash anymore. But I thought it would not crash because of a memory leak since it crashes much before the total amount of available memory is used. Am I wrong?

Quote:

---

Originally Posted by madric

...But I thought it would not crash because of a memory leak since it crashes much before the total amount of available memory is used. Am I wrong?

---

What counters were you watching in Task Manager? Try this short program:

Code:

---

int  main()
{
        BYTE* p(0);
        int count(0);
        do
        {
                p = new BYTE[1024*1024];
                count++;
        } while(p);
        return count;
}

---

Here is what I see in Task Manager. As you see, I used all of the 2GB I had allowed for one process...

You mentioned that you are using multiple threads.

Do you ever access the memory created in one thread from another thread?

@madric: I think I have now a complete image of what your crash situation was; I understood that you already removed the memory leak and that you are simply worried if the crash was not created by something else than these leaks, which have not yet filled the entire RAM you have on your machine...
- well, first of all: your computer may have more than 2gb RAM (I have a 4gb, set-up such as the OS would not use more than 1gb, so... most light apps I have running on my PC take less than 1gb... thus, always having 2gb available for 1 resource desperate application at a time), but... on a 32 bit architecture, the address space of 1 process is no bigger than 2gb.
- second: as you've mentioned, task manager is not a proper tool to monitor what happens to your process; better use Process Monitor, Process Explorer or PsTools Suite; still, lets say your application wasn't using more than 1.4 GB of virtual memory... still, your heap manager might refuse to allocate more virtual pages... from my personal experience, using the heap manager which comes with msvcrt.dll you can safely assume that you can allocate about half of your entire available RAM (as long as that is not 8GB or something :D )... so, lets say it has a limit of 1gb... with or without memory leaks, your code should handle the situation in which you can't allocate more memory. Remember, your process needs a lot of memory for everything else: loaded modules, stack for each threads, and so on... If your application design is made in such way that you limit the number of concurent threads and the maximum limit of allocated memory by each thread, then there's less concern about what can happen if suddenly your heap manager refuses to commit more virtual pages for you. Now that you've removed your memory leaks, shouldn't be more concerned... since your application would work just fine in 99% of regular production environments. It might fail a stress test... but would work perfect in normal, acceptable environment.
A few years ago, I've been working on a rendering engine that needed a lot of graphics card and RAM resources, as well as CPU time. Was designed as MT, but with fixed number of threads. Because of the things described above, I had to start reusing tiles of imagery allocated as soon as the half total RAM or 1gb limit was reached (which ever was smaller), or else, allocation of new tiles would fail soon after that limit. I've tested several HW environments, including dual-processor machines. Another surprise was offered by the call to calloc() which had to be changed into using malloc() and memset(), because for some reason calloc() was failling in situations when separate threads running on different processors were allocating zeroed memory. Today, I would replace memset() with ZeroMemory() API. :)
Let me remind you that you should keep in mind memory fragmentation when having a high number of re-allocations of bigger contiguous memory blocks. You should try reusing those already allocated buffers (since I've noticed your allocations are of same size), instead of deallocating them and re-allocating same size buffers again and again. Would be faster and safer!
With that said, I think the problem you had was generated by the memory leaks, but, if you have any more problems, or you don't wanna have more problems ;) , you should be looking into what I have mentioned above.
Best of luck and happy programming,

Thanks a lot Bornish for sharing your experience and opinion. It was interesting. I will go forward now and I hope my soft will not crash again.
Thanks again!