如何调试损坏的通配符扩展？

Question

我遇到过这样一种情况:bash的通配符扩展有时在我的自动构建中不起作用(它类似于这个question，整个过程都运行在一个在docker容器中创建的chroot中，所以这可能有很多原因(损坏的libc，损坏的shell，等等)。我尝试使用strace，但结果并不能帮助我分析问题。

工作案例的第一行显示了扩展的file-name：

$ 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或任何其他工具对其进行调试？

Answer 1

我编写了一个调用chroot的最小python脚本，就像我的构建系统调用它一样，然后我运行了strace -f -v script.py

这使我发现问题是由于系统调用getdents失败，在googling上搜索了一下之后，我发现这是一个glibc/内核错误，与getdents返回64位值有关(对于ext4系统，getdents即使目录中只有几个文件，也可以返回非常高的值，因为该值是一个哈希值)，但调用者期望的是32位值：https://bugzilla.kernel.org/show_bug.cgi?id=205957

另请参阅https://unix.stackexchange.com/questions/528361/dash-not-expanding-glob-wildcards-in-chroot