Subject: E: /usr/bin/ssh-askpass[39]: too many open files (3 -> 212): Success

From: Timo Weingärtner <[email-masked]>
Date: Sat, 14 Sep 2024 22:52:27 +0200

Package: kwalletcli
Version: 3.03-1+b1
Severity: normal
File: /usr/bin/kwalletaskpass

$ ssh-keygen -t ed25519 -f /tmp/test
$ ssh-add /tmp/test < /dev/null
E: /usr/bin/ssh-askpass[39]: too many open files (3 -> 212): Success
$ echo $?
1

key is not added to the agent

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kwalletcli depends on:
ii  libc6              2.40-2
ii  libgcc-s1          14.2.0-3
ii  libkf5coreaddons5  5.115.0-2
ii  libkf5i18n5        5.115.1-2+b1
ii  libkf5wallet-bin   5.115.0-4
ii  libkf5wallet5      5.115.0-4
ii  libqt5core5t64     5.15.13+dfsg-4
ii  libqt5widgets5t64  5.15.13+dfsg-4
ii  libstdc++6         14.2.0-3
ii  mksh               59c-39

Versions of packages kwalletcli recommends:
ii  gpg-agent [gnupg-agent]     2.2.43-8+b1
ii  kwalletmanager              4:22.12.3-1+b1
ii  openssh-client              1:9.8p1-8
ii  pinentry-curses [pinentry]  1.2.1-4+b1
ii  pinentry-qt [pinentry]      1.2.1-4+b1

kwalletcli suggests no packages.

-- no debconf information

---

From: Thorsten Glaser <[email-masked]>
Date: Sat, 14 Sep 2024 21:45:58 +0000 (UTC)

Hi Timo,

>key is not added to the agent

this is quite puzzling.

First guess: is $DISPLAY set and points to a usable X11 server?

Second guess: /usr/bin/pinentry points to a real one, not to
pinentry-kwallet, right? (Otherwise, there can be recursion.)

Third… please put “set -xv” in the top of the script and retry,
for debugging. Out of ideas, otherwise.

Thanks,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :)    15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?	-- ~/.Xmodmap wonders…

---

From: Timo Weingärtner <[email-masked]>
Date: Sun, 15 Sep 2024 11:14:20 +0200

reassign 1081794 src:mesa
tags 1081794 + upstream
retitle 1081794 file descriptor leak mesa_shader_cache_db
severity 1081794 important

Hallo,

> First guess: is $DISPLAY set and points to a usable X11 server?

Yes, this is a pure X11 session, no wayland.

> Second guess: […]
> Third… […]

Did all that, including strace'ing, was puzzled by a jump in FD numbers there.

> Out of ideas, otherwise.

Further investigation shows FDs 10-109 and 110-209 filled with:
.cache/mesa_shader_cache_db/part0/mesa_cache.db
.cache/mesa_shader_cache_db/part0/mesa_cache.idx
through
.cache/mesa_shader_cache_db/part49/mesa_cache.db
.cache/mesa_shader_cache_db/part49/mesa_cache.idx

When running in xterm (started from krunner) instead of konsole, there is only 
the first such run of cache files and mksh doesn't complain.

These files should definitely be opened CLOEXEC.

https://bbs.archlinux.org/viewtopic.php?id=298957

So while there might be a problem in mksh with many FDs, I'm reassigning to 
src:mesa. Because of https://bbs.archlinux.org/viewtopic.php?id=298957 I 
assume an upstream bug.

Since this adds 100 FDs (at least in my case) per exec() of a mesa-using 
binary in the call chain I'm bumbping severity.

Grüße
Timo

---

From: Timo Weingärtner <[email-masked]>
Date: Sun, 15 Sep 2024 12:14:08 +0200

---

From: Guillem Jover <[email-masked]>
Date: Sat, 9 Nov 2024 04:00:34 +0100

Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/11810

Hi!

> binary in the call chain I'm bumbping severity.

This has been reported upstream and now fixed in git. There's the
other related upstream report with the excessive amount of file
descriptors used:

  https://gitlab.freedesktop.org/mesa/mesa/-/issues/11776

It would be nice to get the fix for that backported into the Debian
package before the next mesa release happens upstream.

Thanks,
Guillem