* Bill Allombert <[email protected]> [20090329 22:05]: > On Sun, Mar 29, 2009 at 03:37:06AM +0200, Michael Prokop wrote: > > * Bill Allombert <[email protected]> [20090328 19:27]:
> > Alright, it's "fgets(tmp, MAX_LINE, status)" in read_pkginfo() of > > menu-2.1.41/update-menus/update-menus.cc that fails with errno 9 > > (AKA "Bad file descriptor") when using libc6 2.9-6 from unstable. It > > works just fine with libc6 2.7-18 from lenny though. > this is strange: update-menus checks twice status before using it. > Thanks a lot for all your effort, but I still cannot reproduce this issue: > I tried on an up-to-date sid system and update-menus works fine. Are you using an amd64 system? Because it works fine on my i386 system with current libc6 and menu versions as well. > If you strace update-menus on a working system, you see someting like: > write(2, "update-menus[30226]: Dpkg is not "..., 65) = 65 > pipe([4, 5]) = 0 > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x7ff0b3046780) = 30227 > I am very interested to know what happen on broken systems. > Maybe you can run strace outside the chroot to catch that ? The sad thing is that if update-menus is running under strace (meaning: either directly invoked via strace or when "strace -p $PID" attaches early enough) it's working as supposed to. If I'm catching the process from the chroot to late I just see tons of the mentioned EBADF errors and update-menus keeps hanging. What I get inside strace (note: then update-menus is working fine): write(2, "update-menus[31341]: Dpkg is not"..., 65) = 65 SYS_331(0xff800758, 0x80000, 0xf7dbaff4, 0x90e2928, 0x1) = -1 ENOSYS (Function not implemented) pipe([4, 5]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7c7c718) = 31342 I guess the SYS_331 is just a strace specific thing. regards, -mika-
signature.asc
Description: Digital signature
