Re: update-menus error

[Joost Witteveen <joostje@cistron.nl>]

On Wed, Mar 28, 2001 at 11:29:05PM +0200, Marcus Brinkmann wrote:
> On Wed, Mar 28, 2001 at 11:24:04PM +0200, Cord Beermann wrote:
> > Hallo! Du (Joost Witteveen) hast geschrieben:
> > 
> > >Doesn't matter. It is totally clear what goes wrong, and I assume stracing
> > >wouldn't show much.
> > >
> > >Apparently you are the only one who sees the problem on Hurd. Is your hurd
> > >in any way special (why do the others not see your problem)?
> 
> Joost, we talked about this in the past

Are you sure? I remember talking, but I seem to recall that then the
error message was different.

Anyway, now it seems it's quite clearly a Hurd/libc problem with the fcntl
implementation, and it should be possible to generate a 10-line test
prorgamme for this bug, and maybe get it fixed in Hurd.
This is the code that goes wrong (menu/update-menus.cc:731):

  fd=open(DPKG_LOCKFILE, O_RDWR|O_CREAT|O_TRUNC, 0660);
  if(fd==-1)
    return 0; // used to be 1, but why??? (Should not happen, anyway)
  fl.l_type= F_WRLCK;
  fl.l_whence= SEEK_SET;
  fl.l_start= 0;
  fl.l_len= 0;
  if (fcntl(fd,F_SETLK,&fl) == -1) {
    close(fd);
    if (errno == EWOULDBLOCK || errno == EAGAIN || errno == EACCES)
      return 1;
    cerr<<"update-menus: Encountered an unknown errno (="
        <<errno<<")."<<endl

And, the errno is apparently:

update-menus: Encountered an unknown errno (=1073741942).

i.e., 1073741942, or 2**30+118 (doesn't look very special to me).
As far as I can see, whenever fcntl returns -1, it _should_ set errno
to something more sensible than that.

And, according to linux-2.4.0-test4/include/asm-i386/errno.h, errno=118
means:
#define ENOTNAM         118     /* Not a XENIX named type file */

Not very logical eighter.

To me it seems that just compiling the above code (with some #include's etc)
should also show the bug, and should lead libc/kernel folks quickly to
the problem.

(the fact that it also occurs when update-menus is ran on the command-line,
means that it doesn't matter whether dpkg locks DPKG_LOCKFILE, so one
should be able to use any file for this - but "/var/lib/dpkg/lock" might be best).

Thanks,
joostje