0

I have Delphi Xe3 and service app, which is connecting to 2 databases with ADO (Firebird and SQL Server), up to 100 tcp connections of hardware with Indy TCP server.

After a random working time app give an error "system error code 8 not enough storage is available to process this command" on various operations:

  1. Creating a new thread
  2. New connection to the database etc.

I checked this topic, atom leak fixed in my version System Error. Code: 8. Not enough storage is available to process this command

App monitoring self state automatic: threads count, allocated memory, open handles, all looking fine. There no memory leak in app, local test on 1M operations don't shown any objects on ReportMemoryLeaksOnShutdown

Example: Ok, 1.1.24.8, Threads / Handles: 122 / 736, Memory used: 2958k / 76160k, Uptime 01:06:13.54

For example, last app crash was on 70 threads, 700 open handles, 3M allocated memory by FastMM, 40M memory of windows process

How I can check, what resource are leaking? Thanks

S.S. Big problem, that app crashed on several clients servers, in production work. Local tests never do app crash, even if I makes memory leaks, hard test etc

Update 1

The problem is most likely with the odbc MSSQL driver.

For different versions of drivers, the program runs without failures is different. With the latest version 17.4.2, the program will work for no more than two hours. Most "stable" work with built-in ODBC driver from 2013 year

I do not have full rights on these servers to update drivers on my own, I work through customer support, I cannot check a result quickly

Николай Невзоров
  • 381
  • 4
  • 12
  • 1
    Is it possible for you to test on the production machine? Use Task Manager to see handles, threads, user objects, GDI object, memory use. Repeat the test sevral times along the day to see how it is evolving. Also check what happens when TCP connections are aborted (not closed but aborted) at client side (That is it remains active at server side). – fpiette Jul 11 '21 at 11:21
  • How long does it take before the issue occurs? – Olivier Jul 11 '21 at 11:42
  • I checked handles, threads and other params automaticly by app and manualy in Task manager, all clear even app makes a first errors. App may working several times after first error and log messages to DB, while self-controlling does not restarting app. Last event was: Exception: EThread = Thread creation error: @ Ok, 1.1.24.8, Threads / Handles: 96 / 668, Memory used: 3024k / 73152k, Uptime 01:01:34.34 – Николай Невзоров Jul 11 '21 at 12:00
  • App can work for a week, or maybe just a day. Self control code ( described in my topic https://stackoverflow.com/questions/67693135/delphi-service-app-crashes-at-a-random-time/68046199 ) working fine and if first problem occurs restarting app immediately, but I want to understand why it happends – Николай Невзоров Jul 11 '21 at 12:01
  • You need to debug this. Get a stack trace from the exception - if you're not already, suggest using MadExcept. Then [edit] the question to include that as well as the source code surrounding the exception, wherever you discover it happens. – J... Jul 11 '21 at 12:42
  • Are you creating a new database connection for every request? Or do you have a connection pool? – Olivier Jul 11 '21 at 12:51
  • @Olivier I created a new connection on every request, request executing in new anonimius thread. Connection pooling are disabled in odbc settings and in connection string (pooling=false) – Николай Невзоров Jul 11 '21 at 13:15
  • 2
    @НиколайНевзоров for TThread to fail, you have to be running out of system resources. From this limited information, we can't tell you what resources you are running out of. I suggest using Performance Monitor to log resource usage over time, then you can look at the graphs, maybe you will see what is rising in usage unexpectedly, or see a pattern to the failures. – Remy Lebeau Jul 11 '21 at 13:36
  • @command No, my Dephi version XE3, atomic leak is fixed. Service has no gui objects, desktop heap not affected for me. Count of threads and handles is always normal – Николай Невзоров Jul 12 '21 at 10:02
  • Your compiler might be atom leak fixed. But have you actually looked how much dead atoms exist from other processes that were executed? You're not the only one who ever used a Delphi compiler and then distributed his software - you're most likely using other author's works, too. – AmigoJack Jul 13 '21 at 08:25
  • @ AmigoJack You're right. But restarting the program solve the problem. If there was an atomic leak then the program would not work after restart – Николай Невзоров Jul 13 '21 at 11:56

0 Answers0