Windows handle leaks in SlickEdit versions after v25

[commanderprs]

It appears that SlickEdit v25 is the last version that does not leak handles
on Windows. I have tried v26 and v27 - both of them leak handles
at the rate of hundreds per second even if the editor is completely idle.
After several hours of being open, the editor eventually eats ups all the kernel
space making it impossible for other processes to open any new handles.
At this point the entire system becomes unusable and dies.

The attached screenshot shows the handle count for v25 with about 30 files
open (a mix of Python, Kotlin and TypeScript code). The Task Manager shows
the handle count of a few hundred. More importantly, it does not change at all
when the editor is idle. If I open exactly the same project with exactly
the same set of files in v26 or v27, the Task Manager shows the handle counter
growing rapidly at a constant rate. The rate is very high - hundreds new handles
are open every second.

This indicates that there is a handle leak somewhere in the editor. Most likely,
some background thread is constantly opening new files but does not close them,
leaking the kernel memory.

Just in case, this is on Windows 7 32-bit, although I do not think it matters.

[repayzippy]

It appears that SlickEdit v25 is the last version that does not leak handles
on Windows. I have tried v26 and v27 - both of them leak handles
at the rate of hundreds per second even if the editor is completely idle.
After several hours of being open, the editor eventually eats ups all the kernel
space making it impossible for other processes to open any new handles.
At this point the entire system becomes unusable and dies.

The attached screenshot shows the handle count for v25 with about 30 files
open (a mix of Python, Kotlin and TypeScript code). The Task Manager shows
the handle count of a few hundred. More importantly, it does not change at all
when the editor is idle. If I open exactly the same project with exactly
the same set of files in v26 or v27, the Task Manager shows the handle counter
growing rapidly at a constant rate. The rate is very high - hundreds new handles
are open every second.

This indicates that there is a handle leak somewhere in the editor. Most likely,
some background thread is constantly opening new files but does not close them,
leaking the kernel memory.

basket random

Just in case, this is on Windows 7 32-bit, although I do not think it matters.

How did the consumer react when it happened?  If the client turned off the power, it would be a catastrophic hardware failure, and (nearly) all bets are off.  NTFS journaling should preserve the directory structure, as well as the file allocation tables.  However, pending file content may not have been committed (even if it was committed by the OS and the hard drive returned success, the hard drive firmware may have deferred the actual write for performance reasons, causing it to be lost -- yes, hard drives do this these days to increase throughput numbers).

[commanderprs]

How did the consumer react when it happened?  If the client turned off the power, it would be a catastrophic hardware failure, and (nearly) all bets are off.  NTFS journaling should preserve the directory structure, as well as the file allocation tables.  However, pending file content may not have been committed (even if it was committed by the OS and the hard drive returned success, the hard drive firmware may have deferred the actual write for performance reasons, causing it to be lost -- yes, hard drives do this these days to increase throughput numbers).

It is hard to tell what happens to the operating system once the kernel handle space gets exhausted. The file system may or may not lose data. However, this is irrelevant to this bug. The bug is caused by something in the SlickEdit code not doing the proper FileClose() on all open handles. As a result of that, after some time, not only the editor itself becomes unusable but the entire operating system as well. Even if the file system does not lose any data (which is not the case), it is still a very serious bug.

[Graeme]

Can you try closing your files one at a time and see if the handle leak stops.  If the problem is caused by one specific file or file type, you could maybe send it to slickedit support.  It might be a Windows 7 problem, since no-one else seems to be getting this.