fd leak on wezterm.gui.enumerate_gpus()

[DrKGD]

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

arch, awesomewm, picom

WezTerm version

wezterm 20230424-091344-26090da8

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Function enumerate_gpus increases number of processes for x11 server on use; once the maximum limit is reached, no more processes can be spawned.

This is even worse when enumerate_gpus is used for the configuration, as each event-update and instance will inevitably leak more and more processes.

To Reproduce

1. Spawn a wezterm instance
2. Check number of wezterm related processes with lsof -U, e.g.

lsof -U | grep wezterm | wc -l

Output 76

3. Open Debug Overlay from within a Wezterm Instance and run require('wezterm').gui.enumerate_gpus()
4. Check again number of wezterm related processes with lsof -U, e.g.

lsof -U | grep wezterm | wc -l

Output is now 79

Configuration

Not really config related, but here's how I am using it (I should really cache its value, hotswapping GPUs is not meta yet I guess)

--- Returns first detected discrete GPU with Vulkan support
local has_vulkan = function()
	local gpus = wezterm.gui.enumerate_gpus()
	for _, gpu in ipairs(gpus) do
		if gpu.backend == 'Vulkan' and gpu.device_type == 'DiscreteGpu' then
			return gpu
		end
	end

	return false
end

-- ...

local config = { }

if wezterm.config_builder then
	config = wezterm.config_builder()
end

-- Use GPU by default for the rendering stuff
local vulkan = has_vulkan()
if vulkan then
	config.webgpu_power_preference = "HighPerformance"
	config.webgpu_preferred_adapter = vulkan
	config.front_end = 'WebGpu'
	config.max_fps = 144
end

return config

Expected Behavior

Number of processes stay constant before and after enumerate_gpus execution.

Logs

No visible related LOGS were produced for the event.

Anything else?

out.mp4

[wez]

Please also share the lsof -U | grep wezterm output (not the wordcount, but the actual full output) before and after the enumerate_gpus call on you system

[DrKGD]

D'oh!

Freshly spawned

wezterm-g 95522 deatharte    9u  unix 0x00000000f752c5d1      0t0 1498952 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   13u  unix 0x00000000fa47b9a4      0t0 1498954 /run/user/1000/wezterm/gui-sock-95522 type=STREAM (LISTEN)
wezterm-g 95522 deatharte   16u  unix 0x000000008f1265b1      0t0 1515192 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   19u  unix 0x00000000d735676f      0t0 1515193 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   22u  unix 0x00000000b9de8ea5      0t0 1498981 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   30u  unix 0x00000000e7378924      0t0 1498983 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   34u  unix 0x000000005b375a6f      0t0 1498984 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   35u  unix 0x00000000989312ed      0t0 1498985 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   40u  unix 0x00000000b55eb57b      0t0 1498992 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   42u  unix 0x000000001233a032      0t0 1498993 type=DGRAM (CONNECTED)

Just after running wezterm.gui.enumerate_gpus() (multiple times) from the Debug Overlay like in the demo

wezterm-g 95522 deatharte    9u  unix 0x00000000f752c5d1      0t0 1498952 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   13u  unix 0x00000000fa47b9a4      0t0 1498954 /run/user/1000/wezterm/gui-sock-95522 type=STREAM (LISTEN)
wezterm-g 95522 deatharte   16u  unix 0x000000008f1265b1      0t0 1515192 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   19u  unix 0x00000000d735676f      0t0 1515193 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   22u  unix 0x00000000b9de8ea5      0t0 1498981 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   30u  unix 0x00000000e7378924      0t0 1498983 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   34u  unix 0x000000005b375a6f      0t0 1498984 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   35u  unix 0x00000000989312ed      0t0 1498985 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   40u  unix 0x00000000b55eb57b      0t0 1498992 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   42u  unix 0x000000001233a032      0t0 1498993 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   71u  unix 0x000000000765e0ce      0t0 1508736 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   74u  unix 0x00000000a9a0dd48      0t0 1508737 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   75u  unix 0x00000000471d73e5      0t0 1508738 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   76u  unix 0x00000000238c9179      0t0 1508742 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   77u  unix 0x00000000011bce39      0t0 1508743 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   78u  unix 0x0000000024f360b8      0t0 1508744 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   79u  unix 0x00000000166d8367      0t0 1508748 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   80u  unix 0x00000000c354b428      0t0 1508749 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   81u  unix 0x000000000f8eb791      0t0 1508750 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   82u  unix 0x0000000062521415      0t0 1508754 type=STREAM (CONNECTED)
wezterm-g 95522 deatharte   83u  unix 0x00000000d80fb8fe      0t0 1508755 type=DGRAM (CONNECTED)
wezterm-g 95522 deatharte   84u  unix 0x000000000020ae2b      0t0 1508756 type=DGRAM (CONNECTED)

[wez]

I reported this to the upstream wgpu project:

• wgpu::Instance fd leak gfx-rs/wgpu#3813

[wez]

I fixed this upstream in gfx-rs/wgpu#3924 and now that has been published, main has been updated to point that, resolving this issue in nightly builds starting in about an hour from now.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.