Does not lock memory

I'll care for that ASAP.

Luckily this works fine in Warty, so this change must have been introduced in Hoary.

(In reply to comment #0)

Funnily gpg works fine when I compile it on my desktop (current Hoary, hoary
kernel).

Let's see:

> if( uid ) {
> errno = EPERM;
> err = errno;
> }
> else {
> err = mlock( p, n );
> if( err && errno )
> err = errno;
> }

This part of the code is only compiled if HAVE_BROKEN_MLOCK is #defined. When
configuring gpg on my system, this is _not_ the case and gpg just executes this
code:

    err = mlock( p, n );
    if( err && errno )
        err = errno;

which does what it should. The quoted code is the only place that actually
checks the uid, so I conclude that HAVE_BROKEN_MLOCK must be true on the buildds.

I will attach the test that configure uses, in case you want to check its result
on the buildds.

I see two possibilities:

(1) find out what's wrong on the buildds and fix it
(2) patch away the uid check in above code (feels like a kludge)

James, do you have any idea about this?

Created an attachment (id=803)
configure test for HAVE_BROKEN_MLOCK

Instructions:

$ gcc -o mlocktest mlocktest.c
$ ./mlocktest ; echo $?

The result code is 0 for a normal-behaving mlock(), 1 for a "broken" one and 2
if malloc() fails.

Confirmed:

http://people.ubuntulinux.org/~lamont/buildLogs/g/gnupg/1.2.5-3ubuntu1/gnupg_1.2.5-3ubuntu1_20041124-0624-i386-successful
> checking for mlock... yes
> checking whether mlock is broken... yes

What kernel is this buildd running?

LaMont, please run the test program in some buildd chroots and see what it reports.

The issue here is that the buildd's (having been started from cron/at), have
RLIMIT_MEMLOCK==0, which causes the test to fail. Building outside of the
buildd (or restarting the buildd from an unlimited shell, etc) corrects the
issue. Spec says that ENOMEM is a valid return, hence the test is broken:
[ENOMEM]
   Locking the pages mapped by the specified range would exceed an
implementation-defined limit on the amount of memory that the process may lock.

Fixed in 1.2.5-3ubuntu3 by #if 0'ing the HAVE_BROKEN_MLOCK variable out of
existance in config.h.in (minimal change)

James - would you take care of forwarding this upstream?

gnupg (1.2.5-3ubuntu3) hoary; urgency=low

  * Disable HAVE_BROKEN_MLOCK, since the test fails if ulimit -l 0.

 -- LaMont Jones <email address hidden> Tue, 30 Nov 2004 22:35:20 -0700