Huge memory leak in the Linux kernel (400-500 MB, likely in the video driver) triggered on every opening KiCad with a moderately complex schematic.

[zxmak]

Describe the bug

Every time I open a moderately complex schematic file in KiCad, and then immediately close KiCad without doing anything, the amount of free memory decreases by approximately 400 - 500 MB.

Each new launch of KiCad causes an additional 400 - 500 MB of memory loss. After 8 - 10 launches, the system runs out of memory and becomes unresponsive. After KiCad closes, the system shows reduced available memory, but no running processes account for the missing memory.

The leak appears to occur at the kernel level, most likely within the video driver.
I am attaching a test schematic file (test.kicad_sch) that reproduces the issue reliably.

test.kicad_sch.zip

Please investigate and fix this issue.

Steps to reproduce the behaviour

1. Install a clean Raspberry Pi OS Bookworm 64-bit with the Wayland Labwc compositor.

2. Add the Debian backports repository by running:

sudo nano /etc/apt/sources.list.d/bookworm-backports.list

and adding the following line:

deb http://deb.debian.org/debian bookworm-backports main contrib non-free

3. Install KiCad by running:

sudo apt update && sudo apt install -t bookworm-backports kicad

4. Open test.kicad_sch with the KiCad schematic editor

5. Close the KiCad schematic editor.

6. Observe that approximately 400–500 MB of memory is leaked.

7. Repeat steps 4 and 5 until the system freezes due to running out of memory.

Device (s)

Raspberry Pi 4 Mod. B

System

$ cat /etc/rpi-issue
Raspberry Pi reference 2023-09-22
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 40f37458ae7cadea1aec913ae10b5e7008ebce0a, stage4

$ vcgencmd version
Mar 19 2025 18:24:21 
Copyright (c) 2012 Broadcom
version ca6e8171a80ea46924ffaa629250bfb482f3a02c (clean) (release) (start)

$ uname -a
Linux rpi4 6.12.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.20-1+rpt1~bpo12+1 (2025-03-19) aarch64 GNU/Linux

KiCad:

Application: KiCad Schematic Editor aarch64 on aarch64

Version: 9.0.1+1, release build

Libraries:
	wxWidgets 3.2.2
	FreeType 2.12.1
	HarfBuzz 6.0.0
	FontConfig 2.14.1
	libcurl/7.88.1 OpenSSL/3.0.15 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13

Platform: Debian GNU/Linux 12 (bookworm), 64 bit, Little endian, wxGTK, X11, LXDE-pi-labwc, wayland
OpenGL: Broadcom, V3D 4.2.14.0, 3.1 Mesa 24.2.8-1~bpo12+rpt2

Build Info:
	Date: Apr 10 2025 15:47:08
	wxWidgets: 3.2.2 (wchar_t,wx containers) GTK+ 3.24
	Boost: 1.74.0
	OCC: 7.6.3
	Curl: 7.88.1
	ngspice: 39
	Compiler: GCC 12.2.0 with C++ ABI 1017
	KICAD_IPC_API=ON

Locale: 
	Lang: en_GB
	Enc: UTF-8
	Num: 1,234.5
	Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8)

Logs

There are no error messages in the system log (dmesg) - no new entries appear during the launch/close of KiCad.

Similarly, there is no error output in the console when running eeschema test.kicad_sch from the terminal.

Additional context

No response

[pelwell]

The leak appears to occur at the kernel level, most likely within the video driver.

Please explain your reasoning.

[zxmak]

Please explain your reasoning.

The reasoning is that despite the KiCad process ending and it's PID disappears from process list, the system’s reported free memory does not recover. The lost memory remains occupied and cannot be used by other programs. In particular, no user-space process is holding that memory (it’s not visible in any running program or shared-memory segment).

I checked common shared-memory areas (e.g. /dev/shm) and found nothing unusual – no large temporary files or POSIX segments remain. This suggests the missing memory isn’t tied up in the normal shared-memory filesystem.

Since the KiCad process is gone, and by design its allocated pages should have been freed on exit​, the only remaining explanation is that some kernel component is still holding the memory. In other words, the leak appears to be at the kernel level rather than in user space.

In additon Alt+SysRq+F is unable to free the leaked memory.

KiCad heavily utilizes the GPU for rendering, and since the amount of leaked memory after the process terminates appears to be proportional to the complexity of the schematic's geometry, this leads me to believe that the leak is most likely related to the GPU driver.

[pelwell]

the only remaining explanation is that some kernel component is still holding the memory

I don't think that's true - it's also possible (and I tend to think more likely) that some part of the GUI is still holding resources on behalf of KiCad, even though the process has closed.

[zxmak]

I don't think that's true - it's also possible (and I tend to think more likely) that some part of the GUI is still holding resources on behalf of KiCad, even though the process has closed.

Could you clarify which part of the GUI you believe might be holding these resources?
As I mentioned earlier, there are no processes listed that account for the missing memory, which strongly indicates that the leak is not occurring within user-space processes.

Additionally, I have tested restarting both wf-panel-pi and labwc, which fully resets the GUI, including returning to the login screen. However, immediately after logging back in, more than 3 GB of memory remains occupied, and there are still no processes in the process list that explain this usage.

This further supports the conclusion that the memory leak occurs at the kernel level rather than in user space.

[popcornmix]

I've not very familiar with the v3d driver, but there are some stats here:

$ cat /sys/kernel/debug/dri/fec00000.v3d/v3d_mm 
0x0000000000000001-0x0000000000000003: 2: used
0x0000000000000003-0x0000000000001fa7: 8100: used
0x0000000000001fa7-0x0000000000001fa8: 1: used
0x0000000000001fa8-0x0000000000001fa9: 1: used
0x0000000000001fa9-0x000000000000204b: 162: used
0x000000000000204b-0x00000000000020cb: 128: used
0x00000000000020cb-0x00000000000020cc: 1: used
0x00000000000020cc-0x00000000000020cd: 1: used
0x00000000000020cd-0x0000000000004071: 8100: used
0x0000000000004071-0x0000000000100000: 1032079: free
total: 1048575, used 16496 free 1032079

(there may be others). Does this list appear to increase on each run?

[pelwell]

Yes, it does.

After reboot:

[ 40 lines skipped ]
total: 1048575, used 10676 free 1037899

After 1 open/close cycle:

[ 616 lines skipped ]
total: 1048575, used 106526 free 942049

After 2:

[ 729 lines skipped ]
total: 1048575, used 172085 free 876490

Interestingly, the kernel kmemleak detection isn't showing anything.

[mairacanal]

It's also possible to investigate the BO count with /sys/kernel/debug/dri/fec00000.v3d/bo_stats, but from what @pelwell shared, there is indeed a memory leak.

I solved a similar issue yesterday and sent the fix upstream [1]. It's a long-standing issue that has existed since the driver was introduced, but most likely before 8dd6074 we couldn't see it (as we used to run OOM without using the whole memory space).

@pelwell, could you try [1]? It applies to rpi-6.12.y.

[1] https://lore.kernel.org/dri-devel/ace509ac67221d5a3e7215ea132c8155179850e4.camel@igalia.com/T/

[pelwell]

The having tried the X11 and wayfire options, neither of which seemed to leak, I've switched back to labwc and the results are confusingly variable/different. There are latencies and hysteresis in the system, but after the first run of KiCad I can no longer see consistent growth in memory usage.

I tried with your patch, Maira, and didn't see obvious change. Neither did reverting it.

I'll try a clean install, just in case raspi-config is not putting things back as they were.

[pelwell]

The clean install did not leak to any obvious degree. However, I noticed that your instructions don't quite give the configuration you show - current images still ship with a 6.6 kernel, while you appear to be running 6.12, so you must at least have apt upgraded the kernel.

[pelwell]

Oh, I forget to mention that this time around I got a warning about being unable to use OpenGL and falling back to a software renderer, that I don't remember from last time.

[zxmak]

Does this list appear to increase on each run?

Yes, it grows very much.

0: Just after system reboot, before open kicad, 1: after first start/close cycle, etc:

0: total: 1048575, used 8370 free 1040205
1: total: 1048575, used 88494 free 960081
2: total: 1048575, used 153254 free 895321
3: total: 1048575, used 217288 free 831287
10: total: 1048575, used 651607 free 396968

At open/close cycle 12 error happens on kicad startup:

OpenGL did not shut down properly.
Error: unmapping vertices buffer: invalid operation
Could not use OpenGL, falling back to software rendering
Error: creating buffer during defragmentation: out of memory

I also noticed that if audio is playing in the background (e.g., internet radio via mpg123 or just a sound file in VLC), starting or closing KiCad causes the audio to momentarily drop out, accompanied by very loud crackling from the speakers. This issue occurs even when opening very small schematics containing only a few lines.

[zxmak]

It's also possible to investigate the BO count with /sys/kernel/debug/dri/fec00000.v3d/bo_stats, but from what @pelwell shared, there is indeed a memory leak.

it also grows (tested just after reboot with only lxterminal in background):

$ cat /sys/kernel/debug/dri/fec00000.v3d/bo_stats
allocated bos:          60
allocated bo size (kb): 40652

$ eeschema test.kicad_sch
$ cat /sys/kernel/debug/dri/fec00000.v3d/bo_stats
allocated bos:          673
allocated bo size (kb): 397316

$ eeschema test.kicad_sch
$ cat /sys/kernel/debug/dri/fec00000.v3d/bo_stats
allocated bos:          619
allocated bo size (kb): 645152

$ eeschema test.kicad_sch
$ cat /sys/kernel/debug/dri/fec00000.v3d/bo_stats
allocated bos:          777
allocated bo size (kb): 940376

$ eeschema test.kicad_sch
$ cat /sys/kernel/debug/dri/fec00000.v3d/bo_stats
allocated bos:          986
allocated bo size (kb): 1209132

[mairacanal]

I was able to reproduce this error exclusively in the RPi 4 (which makes sense as it's a less powerful device, so it might trigger more sched timeouts). I wasn't able to reproduce it with RPi 5 even using the same SD card.

In order to check if there was a buffer object leak, I ran eeschema test.kicad_sch twice and then systemctl stop lightdm (which kills the graphical interface). With that, I was able to check that even without the graphical interface, there are BOs that weren't freed, which indicates a memory leak.

mairacanal@raspberrypi:~ $ export DISPLAY=:0
mairacanal@raspberrypi:~ $ eeschema kicad/test.kicad_sch
mairacanal@raspberrypi:~ $ eeschema kicad/test.kicad_sch
mairacanal@raspberrypi:~ $ sudo systemctl stop lightdm
mairacanal@raspberrypi:~ $ cat /sys/kernel/debug/dri/128/bo_stats
allocated bos:          193
allocated bo size (kb): 551940

Now, after applying the patch mentioned previously [1], I get:

mairacanal@raspberrypi:~ $ export DISPLAY=:0
mairacanal@raspberrypi:~ $ eeschema kicad/test.kicad_sch
mairacanal@raspberrypi:~ $ eeschema kicad/test.kicad_sch
mairacanal@raspberrypi:~ $ sudo systemctl stop lightdm
mairacanal@raspberrypi:~ $ cat /sys/kernel/debug/dri/128/bo_stats
allocated bos:          0
allocated bo size (kb): 0
mairacanal@raspberrypi:~ $ uname -r
6.12.25-fix-timeout-leak-v8+

Therefore, from what I could see, [1] should fix this issue, but it would be great to hear some feedback, as Phil didn't get conclusive results. Maybe @zxmak can try the patch and see if it helps.

[1] https://lore.kernel.org/dri-devel/ace509ac67221d5a3e7215ea132c8155179850e4.camel@igalia.com/T/

[pelwell]

Thanks for testing it Maira. I'll put your patch in a PR, then it will be easy for @zxmak to try it.