[scintilla:bugs] #2506 Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Joseph Betz
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Tue Mar 31, 2026 08:42 PM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (88.3 kB; image/png)
Creating multiple instances of Scintilla in an application results in a leak of GPU memory. Each time a new instance is created, GPU memory is allocated, and it is never cleaned up when the associated window is destroyed.
This is observable on Windows 10 using the Details tab of the Task Manager with the Dedicated GPU memory column visible.
As I workaround, I disabled DirectWrite, so no additional GPU memory is allocated when new instances are created. However, it does not clean up memory claimed by existing instances.
I ran into this while using the Dolphin Smalltalk IDE, which creates a new Scintilla instance each time a text editor is opened rather than creating multiple documents within a single instance. Since this is a nonstandard use of Scintilla, it may be difficult to reproduce with Scite or Notepad++, but a simple script that creates and destroys multiple instances should suffice?
Sent from sourceforge.net because scintill...@googlegroups.com is subscribed to https://sourceforge.net/p/scintilla/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/scintilla/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Neil Hodgson
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin.
The particular technology setting may affect behaviour with Technology::DirectWrite1 being more complex and with newer code.
Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory used after the second openings then the use may be of this form.
Sometimes graphics drivers have bugs. The leak should be verified on a machine with a different brand GPU.
Joseph Betz
Can't see anything obvious in the allocation and deallocation of Direct* resources. They are handled through WRL::ComPtr so should all be released when deleting the ScintillaWin.
Thanks for looking into it.
Sometimes code allocates memory pools which are retained to avoid extra work. Open multiple Scintilla windows then close them and open the same windows again. If there is a similar amount of memory used after the second openings then the use may be of this form.
I don't understand. How do you reopen a window that has already been closed?
Sometimes graphics drivers have bugs. The leak should be verified on a machine with a different brand GPU.
The leak happens on a NVIDIA GeForce GT 1030, driver version 32.0.15.6094. I updated it to v32.0.15.8228 and the behaviour doesn't change. The versions are about two years apart.
In any case, I'll see if I can find other Dolphin users with different hardware to try and reproduce it.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Wed Apr 01, 2026 03:51 AM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)
Neil Hodgson
How do you reopen a window that has already been closed?
Open a new similar window: same text and size since GPU memory increases with window size. The purpose is to allocate in a similar pattern to the initial sequence of window creations. That way, the allocated pool (if that is the implementation) may be re-used if the allocations were released to the pool during window destructions.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Sat Apr 04, 2026 05:28 PM UTC
Owner: nobody
Attachments:
Joseph Betz
Open a new similar window: same text and size since GPU memory increases with window size.
So, if I open a Scintilla window of size 1140@942, about 10mb of GPU memory gets allocated.
If I open another with the same text and size, another 10mb gets allocated.
If I then close one of those windows, and then open another similar window, another 5mb gets allocated. So, roughly half.
If I open another window, it's back to allocating 10mb each time.
At no point after closing a window does the GPU memory go down by 10mb, but it will occasionally go down by 5mb, usually a few seconds after closing. I haven't been able to reliably produce this. It seems somewhat random.
The purpose is to allocate in a similar pattern to the initial sequence of window creations. That way, the allocated pool (if that is the implementation) may be re-used if the allocations were released to the pool during window destructions.
Since the memory always goes up whenever a new Scintilla window is opened, I think that disproves the theory of memory pooling appearing to cause a leak.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Wed Apr 08, 2026 03:52 AM UTC
Owner: nobody
Attachments:
Neil Hodgson
Deallocation failures may be found by turning on the Direct2D debug flag with this change.
diff -r fd871c692138 win32/SurfaceD2D.cxx
--- a/win32/SurfaceD2D.cxx Tue Apr 07 09:25:27 2026 +1000
+++ b/win32/SurfaceD2D.cxx Sat Apr 11 15:57:32 2026 +1000
@@ -108,7 +108,7 @@
hDLLD2D = ::LoadLibraryEx(TEXT("D2D1.DLL"), {}, loadLibraryFlags);
D2D1CFSig fnD2DCF = DLLFunction<D2D1CFSig>(hDLLD2D, "D2D1CreateFactory");
if (fnD2DCF) {
- const D2D1_FACTORY_OPTIONS options{};
+ const D2D1_FACTORY_OPTIONS options{ D2D1_DEBUG_LEVEL_INFORMATION };
// A multi threaded factory in case Scintilla is used with multiple GUI threads
fnD2DCF(D2D1_FACTORY_TYPE_MULTI_THREADED,
__uuidof(ID2D1Factory1),
At process exit, this may produce a report in the Visual C++ debugger like this artificially provoked one.
15:56:21:877 An interface [0000021F7C0A5788] was created but not released. Use 'dps 0000021F7C0A5728' to view its allocation stack.
15:56:21:877 Object type: ID2D1HwndRenderTarget
15:56:21:877 Size: 809 x 964
15:56:21:877 Format: DXGI_FORMAT_B8G8R8A8_UNORM
15:56:21:877 Alpha mode: D2D1_ALPHA_MODE_IGNORE
15:56:21:877 HWND: 0x1206C8
15:56:21:877 Outstanding reference count: 1
15:56:21:877
15:56:21:877 D2D DEBUG ERROR - Memory leaks detected.
15:56:21:877 A breakpoint instruction (__debugbreak() statement or a similar call) was executed in SciTE.exe.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Wed Apr 08, 2026 11:48 AM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)
Joseph Betz
Indeed, it produced a debug error:
An interface [2C7D2690] was created but not released. Use 'dps 2C7D2660' to view its allocation stack.
Object type: ID2D1Factory
Factory type: D2D1_FACTORY_TYPE_MULTI_THREADED
Outstanding reference count: 1
D2D DEBUG ERROR - Memory leaks detected.
Though I'm not sure this is the same issue. There is only ever one object listed, no matter how many Scintilla instances I open and close.
In any case, it's worth fixing to see if the behavior changes.
Can you tell whether this is a bug in Scintilla or if my application is missing some sort of call to release resources?
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Sat Apr 11, 2026 06:04 AM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)
Joseph Betz
Okay, I see that the ID2D1Factory is a global variable that will be released on process exit. So it should be innocuous.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Sat Apr 11, 2026 07:08 PM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)
Neil Hodgson
There is some messiness [#1602], [#1603] with releasing the factory so it isn't released on some execution paths.
It's possible some caches are attached to the factory but the size of the leak looks like a pixel buffer.
1140 * 942 = 1,073,880.
1,073,880 * 4 (bytes per pixel) = 4,295,520.
It is possible the x dimension is extended out to match some alignment requirement as may the whole allocation.
This is a reasonable match for some 5MB / 10MB allocations.
Another aspect is scaling. 10MB would match the above image size at 1.5x scaling. 1.5*1.5*4,295,520 = 9,664,920.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Sat Apr 11, 2026 07:47 PM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)
Neil Hodgson
Since I can't reproduce this issue, I can't fix it and won't be working on it further.
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Sun Apr 12, 2026 10:55 PM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)
Neil Hodgson
- status: open --> open-works-for-me
[bugs:#2506] Dedicated GPU memory isn't cleaned up when Scintilla instances are destroyed
Status: open-works-for-me
Group: Bug
Labels: scintilla Memory Leak gpu DirectWrite
Created: Tue Mar 31, 2026 08:42 PM UTC by Joseph Betz
Last Updated: Fri Apr 24, 2026 10:20 PM UTC
Owner: nobody
Attachments:
- 563228823-0100f148-a03a-482d-a285-e0ca4e767052.png (sourceforge.net) (88.3 kB; image/png)