On Sun, Mar 29, 2009 at 11:00:33PM +0200, Michael Prokop wrote: > * Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> [20090329 22:05]: > > On Sun, Mar 29, 2009 at 03:37:06AM +0200, Michael Prokop wrote: > > > * Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> [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?
Yes. > Because it works fine on my i386 system with current libc6 and menu > versions as well. Good to know! > > 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. This suggest some kind of race-condition between update-menus and the kernel. Could you try gdb /usr/bin/update-menus to see if it also works ? If it fails, then you can try to do single-step in read_pkginfo() to see what happen. The fact that update-menus -v output the list of package seems to imply that it does pipe([x, 1]) or pipe([x, 2]). Well, at least, we can tell which one it is: try update-menus -v >menu.out 2>menu.err and see whether the package list is in menu.out or menu.err. > 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. Actually 'SYS_331' means the syscall number 331. However /usr/include/asm/unistd_64.h stops at 294, so maybe this is a false syscall added by strace so it can catch it. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
