Depurando um processo de thumbnailer lento

Estou tentando depurar um comportamento de desempenho peculiar no processo de geração de miniaturas para eog, especificamente gdk-pixbuf. Os arquivos mínimos para reproduzir estão aqui:

https://github.com/nbeaver/gdk-pixbuf-bug

A árvore de processos fica assim:

systemd,1 splash
  `-plasmashell,4366
      `-konsole,6783
          `-bash,6793
              `-make,6949 reproduce
                  `-eog,6973 /usr/share/doc/docutils-doc/docs/user/images
                      `-bwrap,10071 --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib64 /lib64 --ro-bind /lib /lib --ro-bind /sbin /sbin --proc /proc --dev /dev --chdir / --setenv GIO_USE_VFS local --unshare-all --die-with-parent --bind /tmp/gnome-desktop-thumbnailer-2HUN5Z /tmp --ro-bind /usr/share/doc/docutils-doc/docs/user/images/s5-files.svg /tmp/gnome-desktop-file-to-thumbnail.svg --seccomp 11 /usr/bin/gdk-pixbuf-thumbnailer -s 128 file:///tmp/gnome-desktop-file-to-thumbnail.svg /tmp/gnome-desktop-thumbnailer.png
                          `-bwrap,10074 --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib64 /lib64 --ro-bind /lib /lib --ro-bind /sbin /sbin --proc /proc --dev /dev --chdir / --setenv GIO_USE_VFS local --unshare-all --die-with-parent --bind /tmp/gnome-desktop-thumbnailer-2HUN5Z /tmp --ro-bind /usr/share/doc/docutils-doc/docs/user/images/s5-files.svg /tmp/gnome-desktop-file-to-thumbnail.svg --seccomp 11 /usr/bin/gdk-pixbuf-thumbnailer -s 128 file:///tmp/gnome-desktop-file-to-thumbnail.svg /tmp/gnome-desktop-thumbnailer.png
                              `-gdk-pixbuf-thum,10075 -s 128 file:///tmp/gnome-desktop-file-to-thumbnail.svg /tmp/gnome-desktop-thumbnailer.png

Do stracelog , parece que /usr/bin/gdk-pixbuf-thumbnailerestá gastando cerca de 30 segundos olhando os arquivos de fonte:

22:44:05 munmap(0x7fd491988000, 20930832) = 0 <0.000558>
22:44:05 openat(AT_FDCWD, "/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc", O_RDONLY) = 5 <0.000060>
22:44:05 fcntl(5, F_SETFD, FD_CLOEXEC)  = 0 <0.000014>
22:44:05 fstat(5, {st_mode=S_IFREG|0644, st_size=20930832, ...}) = 0 <0.000013>
22:44:05 mmap(NULL, 20930832, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fd491988000 <0.000021>
22:44:05 close(5)                       = 0 <0.000011>
22:44:06 munmap(0x7fd491988000, 20930832) = 0 <0.000525>
22:44:06 openat(AT_FDCWD, "/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc", O_RDONLY) = 5 <0.000076>
22:44:06 fcntl(5, F_SETFD, FD_CLOEXEC)  = 0 <0.000013>
22:44:06 fstat(5, {st_mode=S_IFREG|0644, st_size=20930832, ...}) = 0 <0.000012>
22:44:06 mmap(NULL, 20930832, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fd491988000 <0.000023>
22:44:06 close(5)                       = 0 <0.000013>
<snip>
22:44:31 stat("/usr/share/fonts/opentype/stix-word/STIXMath-Regular.otf", {st_mode=S_IFREG|0644, st_size=476872, ...}) = 0 <0.000024>
22:44:31 openat(AT_FDCWD, "/usr/share/fonts/opentype/stix-word/STIXMath-Regular.otf", O_RDONLY) = 5 <0.000026>
22:44:31 fcntl(5, F_SETFD, FD_CLOEXEC)  = 0 <0.000014>
22:44:31 fstat(5, {st_mode=S_IFREG|0644, st_size=476872, ...}) = 0 <0.000013>
22:44:31 mmap(NULL, 476872, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fd49c26a000 <0.000023>
22:44:31 close(5)                       = 0 <0.000015>

Existe um SVG específico que aciona esse comportamento. No entanto, não basta apenas rodar eog ou gdk-pixbuf-thumbnailerno SVG. Esse comportamento só acontece quando:

• rodando eogem um diretório;

• existe um SVG específico no diretório que ainda não possui uma miniatura em ~/.cache/thumbnails/.

  (Eu uso touchpara atualizar o timestamp do SVG e fazer o thumbnailer rodar novamente todas as vezes.)

• há pelo menos uma outra imagem no mesmo diretório;

• e a outra imagem tem um nome de arquivo que agrupa antes do nome de arquivo SVG.

  (Se o nome do arquivo for agrupado após o nome do arquivo SVG, ele gerará a miniatura em menos de um segundo. Caso contrário, levará cerca de 30 segundos.)

Existem alguns outros quebra-cabeças também. No stracelog , os tempos do relógio de parede não parecem corresponder ao tempo gasto nas chamadas do sistema. Eu corri eogcom stracea -fbandeira:

-f

Rastreie processos filhos conforme eles são criados por processos atualmente rastreados como resultado das chamadas de sistema fork(2), vfork(2) e clone(2).

e eu também tentei o -ffsinalizador:

-ff

Se a -o filenameopção estiver em vigor, cada rastreamento de processo será gravado filename.pidonde pidestá o ID numérico do processo de cada processo.

mas em ambos os casos gdk-pixbuf-thumbnailernão aparece nos arquivos de log dos processos filhos.

Também estou tendo problemas para executar (algo gdbsobre gdk-pixbuf-thumbnailer "O destino e o depurador estão em namespaces PID diferentes"), então não posso dizer onde está ficando preso.

$ sudo gdb -p 20789
[sudo] password for nathaniel:
<snip>
Error while mapping shared library sections:
Could not open `target:/lib/x86_64-linux-gnu/libbsd.so.0' as an executable file: No such file or directory

warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.
(gdb) quit
Detaching from program: target:/newroot/usr/bin/gdk-pixbuf-thumbnailer, process 20789

Eu estou supondo que isso tem a ver com o bwraprecipiente.

Versão informação:

$ apt-cache policy libgdk-pixbuf2.0-bin eog
libgdk-pixbuf2.0-bin:
  Installed: 2.36.11-2
  Candidate: 2.36.11-2
  Version table:
 *** 2.36.11-2 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
eog:
  Installed: 3.28.1-1
  Candidate: 3.28.1-1
  Version table:
 *** 3.28.1-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

Minhas perguntas são:

• Este bug é reproduzível em outras máquinas e outras versões?

  (Acontece que estou usando o Ubuntu 18.04, mas quero saber se isso acontece em outras distribuições.)

• Por que não está strace -fpegando /usr/bin/gdk-pixbuf-thumbnailer como um processo filho de eog?

  Usa eogum método incomum para criar processos filho?

• Como posso usar gdbpara anexar ao /usr/bin/gdk-pixbuf-thumbnailerprocesso e ver em qual função ele está gastando tempo?

• O que pode estar causando esse comportamento?