Как отладить сломанное расширение подстановочного знака? - PullRequest
0 голосов
/ 22 апреля 2020

У меня есть ситуация, когда кажется, что расширение подстановочного знака bash иногда не работает в моей автоматической сборке (это похоже на этот вопрос , все работает внутри ch root создан внутри docker контейнера, поэтому может быть много причин, почему он не работает (неработающая библиотека c, сломанная оболочка и т. д. c.). Я пытался использовать strace, но результат не помог мне проанализировать проблема.

В первой строке рабочего случая показано расширенное имя файла:

$ ls /tmp/
linux-image-4.9.124.deb
$ strace ls /tmp/linux*deb
execve("/bin/ls", ["ls", "/tmp/linux-image-4.9.124"...], [/* 23 vars */]) = 0
...

А в случае сбоя показано, что * не было расширено:

$ ls /tmp/
linux-image-4.9.124.deb
$ strace ls /tmp/linux*deb
execve("/bin/ls", ["ls", "/tmp/linux*deb"], [/* 23 vars */]) = 0
...

set -o показывает noglob off в обоих случаях

Как я могу отладить это, например, с помощью strace / gdb или любого другого инструмента?

1 Ответ

1 голос
/ 24 апреля 2020

Я написал минимальный python скрипт, вызывающий ch root так же, как моя сборочная система вызывает его, а затем я запустил strace -f -v script.py

Это позволило мне выяснить, что проблема сбой системного вызова getdents, и, немного погуглив, я обнаружил, что это ошибка glibc / kernel, связанная с тем, что getdents возвращает 64-битное значение (для системы ext4 getdents могут возвращать очень высокие значения, даже если в каталоге находятся только несколько файлов, потому что это значение ha sh), но вызывающий объект ожидает 32-битное значение: https://bugzilla.kernel.org/show_bug.cgi?id=205957

См. также https://unix.stackexchange.com/questions/528361/dash-not-expanding-glob-wildcards-in-chroot

...