EOutOfResources

I'm creating a server application, which will be run 24 hours a day. After some hours I run the application I get these error messages:

"Not enough storage is available to process this command" and
"Out of system resources"

Both messages were sent by exception EOutOfResources and the Sender
class is TSyncManager.

I can hardly trace and debug this error because the error always occur
while I'm away. I tried to get some more information about the exception
to get me some more idea where the bug might be located, but I cannot
find enough information about it.

Can anybody help me with some information about the exception and those error messages, what it is and what actions might cause those errors?

From Delphi help :
EOutOfResources is the exception class for unsuccessful attempts to allocate handles.
EOutOfResources is raised when an application attempts to create a Window or widget handle and there are no more handles to allocate.

Your application is just running out of resources and that's probably because you're leaking memory. The best way to find these errors is by maintaining a log file. Then, evert componet you use should write to the logfile when it is created and when it is destroyed. (And some other important events.) If possible, try to generate unique ID's for every new object.

The way I do this is by modifying the constructors and destructors of every component. Here you add code to write to the logfile.

Now, run your application for a while and then check if every component that is created is also freed sooner or later. I think in your case, you forget to free some objects, thus you run out of resources. The log will provide a hint about where it happens.

For a very useful logging method download http://www.workshop-alex.org/Sources/Debug/debug.zip from my site. This is a small project that compiles to a DLL. This DLL will write information to a specially formatted log file. Add the unit cp_Debug into your project and all you have to do is add WriteLn() statements in your code. The unit adds two new textfiles to your application. One is called "Log" and adds timestamps to every new line. The other is called "Debug" and is a plain-text file.
The advantage of using this DLL/Unit is simple. If the DLL isn't in the same folder as the executable, no log information will be generated. However, if it can find the DLL, it will load it and write all kinds of log information to two log files. (One .Log and one .Debug file.)

The code is pretty threadsafe too, btw. It has helped me quite often in detecting small errors and memory leaks and if you don't include the DLL with your final version, it won't generate any log information either.

Hmmm. Checking your latest response now. It could well be that you create new JPGs faster than you destroy them. If you create 50 JPGs per second and only destroy 45 JPGs per second, then every second you just keep 5 JPGs in memory. In one minute this will have grown to 5*60=300 JPGs. An hour later you have 18000 JPGs in memory. After 5 hours it will increase to 90000 images waiting to be destroyed...

In that case, check the length of the queue... If it's past a certain limit, just let the system delay a while or speed up the process that is freeing the JPGs.

The free is not really required since the images are stored on a stack, AFAIK. Somewhere else in the code, this stack could be freed again. It keeps pushing images on the stack until there are 200 items in the stack. Then it starts reusing images from the stack.

But this limit might not be enough, though. Besides, I don't see where the BMP that is passed to this function is freed... It could well be that he's forgetting to free these bitmaps. :)

Workshop_Alex: About the bitmaps, I get those from another third-party component (I assume that there is no leak in that component) and it's his responsibility to destroy the bitmap (after the event). And about the 5 jpgs/min in the memory, I reuse them for another images, I don't really destroy them until the application is terminated.

Ivanov G: The jpgs are freed just before the application is terminated, so I don't free them on that same method.

Still, you must be leaking memory somewhere and it could well be in the component that you're using. Try adding bmp.Free; at the end of your code and see what happens. If you're not supposed to free it, it will crash in minutes. Otherwise, it's the leak...

My experience with third-party components are that they are about as buggy as my own code. And sometimes even worse... If possible, check the sourcecode of this component to check if he's indeed freeing the bitmap.

Since it takes hours before the system crashes, I assume it's just leaking small amounts of memory all the time. In general, the system would start to slow down after a while because it starts swapping and this slowdown will lengthen the whole process a bit further before the system finally gives up. In these situations the task manager can be a great help too since it will show you the amount of memory but also the number of resources that you are using. Check if these are just growing. You don't have to sit up all night to just check the increase in memory or file handles.
But it is clear something is leaking...

in my company i use sleuth codewatch for finding memory leaks
its quite easy to use and generates more messages than you wanted to get ;-)

i don't think posting code will help much as it is possible that a small helperfunction
causes the leak and it would be no good idea to post too much code as nobody would
check it as a whole (beside the copyright problems).

If your application work 24/7, then it's might have memory fragmentation, Borland memory manager didn't work well for these types of application, replacing the memory manager with better one, will improve the performance and will fix a lot of these types of problems, the memory manager I suggest you to look about is the one from NexusDB, its work much better than Borland one

EOutOfResources isn't caused only by memory leaks. It can be caused anytime a memory allocation fails for any reason whatsoever, even if there's memory available.

Our application started experiencing these errors rather commonly when it got big. We didn't have memory leaks, and it would happen even when the application had just started up, when the user requested the first few forms -- it tends to go away after that, though it's not consistent. We created a set of #define's to place around every call to new() that involved a borland-provided class, VCL or otherwise. The #define would automatically retry (while loop) if the try/catch inside the #define caught an EOutOfResources exception (later, I think we added two or three other exceptions to the list, as they all had similar issues.) Oddly enough, the second or third loop will generally not have any errors, and our code continues to execute just fine. I've never seen it loop infinitely. The user never sees anything, either (but it's still annoying in debug mode, as the IDE catches the exception first.) As someone else pointed out, borland's memory functions may not be perfect, but don't assume it's always caused by memory leaks. In our case, it just didn't feel like allocating the new objects on the first request, but would have no trouble doing so later. I'm posting the code of these #define's below:

We knew about this problem from other projects, we knew other programming teams had never found a solution to make the exceptions go away permanently, and the problem didn't appear right away. We're still using Builder5 for this project; my girlfriend is using Builder6 for some new projects and says she's not yet run into this same problem (but plenty of others.) Give it a try, see if the problem goes away with some simple retrying.