[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Délai de 25 secondes




On 11/9/23 15:12, Seb wrote:

Bonjour,


poll([{fd=11, events=POLLIN}], 1, 25000
Là il attend un évènement sur le file descripteur 11, il faudrait repérer au dessus un appel open (ou nom approchant) que retourne 11 pour voir à quelle ressource ça correspond

J'ai redirigé la sortie de strace vers un fichier "trace".
Ensuite:

~/temp> egrep 'poll.*fd=11|^open.*= 11' trace | cat -n
     1    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])      2    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])      3    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])      4    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])      5    poll([{fd=11, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)      6    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache", O_RDONLY) = 11      7    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11      8    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so", O_RDONLY|O_CLOEXEC) = 11      9    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so", O_RDONLY|O_CLOEXEC) = 11
     [...]

C'est le "poll" de la ligne 5 qui bloque.

Je ne vois donc pas d'openat renvoyant 11 dans les lignes qui le précèdent.


Je devine qu'un processus (j'ignore lequel) a appellé eventfd, qui est très utile mais spécifique à Linux:

https://man7.org/linux/man-pages/man2/eventfd.2.html


Peut-être qu'il serait utile de télécharger le code source de pavucontrol https://freedesktop.org/software/pulseaudio/pavucontrol/ et d'y chercher les appels à eventfd.


Sinon, un rapport de bogue sur https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait être utile.



ls -l /proc/$(pidof pavucontrol)/fd

Cela donne, pendant le chargement de pavucontrol :

~> ls -l /proc/$(pidof pavucontrol)/fd
total 0
lrwx------ 1 seb seb 64 Nov  9 16:07 0 -> /dev/pts/11
lrwx------ 1 seb seb 64 Nov  9 16:07 1 -> /dev/pts/11
lrwx------ 1 seb seb 64 Nov  9 16:07 10 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov  9 16:07 11 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov  9 16:07 2 -> /dev/pts/11
lrwx------ 1 seb seb 64 Nov  9 16:06 3 -> 'socket:[443606]'
lrwx------ 1 seb seb 64 Nov  9 16:07 4 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov  9 16:07 5 -> 'socket:[444861]'
lrwx------ 1 seb seb 64 Nov  9 16:07 6 -> 'socket:[440203]'
lrwx------ 1 seb seb 64 Nov  9 16:07 7 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov  9 16:07 8 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov  9 16:07 9 -> 'socket:[444862]'

man proc a quelques infos sur "anon_inode:[eventfd]", mais ça ne m'avance
pas beaucoup :

              For file descriptors that have  no  corresponding inode  (e.g.,               file    descriptors   produced   by   bpf(2), epoll_create(2),               eventfd(2),  inotify_init(2),  perf_event_open(2), signalfd(2),               timerfd_create(2), and userfaultfd(2)), the entry will be a sym-
              bolic link with contents of the form

                  anon_inode:file-type

              In many cases (but not all),  the  file-type  is surrounded  by
              square brackets.

              For  example, an epoll file descriptor will have a symbolic link
              whose content is the string anon_inode:[eventpoll].

man 2 eventfd parle d'un mécanisme d'attente :

       eventfd()  creates  an  "eventfd  object"  that can be used as an event        wait/notify mechanism by user-space applications, and by the kernel  to
       notify  user-space  applications of events.

Cela ne m'avance guère.

Quelqu'un sait-il donner du sens à tout cela ?


Pour ma part, je cherche des contributeurs pour le moteur d'inférences http://refpersys.org/ (avec code en https://github.com/RefPerSys/RefPerSys/ ....)


Dans quelque temps (j'espère quelques mois) RefPerSys pourrait aider à chasser ce genre de bogue.


Librement

--
Basile Starynkevitch
 <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/


Reply to: