Mail Archives: cygwin/2011/12/04/14:28:06
On Sun, Dec 04, 2011 at 12:04:08AM +0100, Corinna Vinschen wrote:
>On Dec 3 16:30, Christopher Faylor wrote:
>> On Sat, Dec 03, 2011 at 01:44:59PM -0500, Christopher Faylor wrote:
>> >On Tue, Nov 29, 2011 at 09:19:10PM -0600, Yaakov (Cygwin/X) wrote:
>> >>For some time now, snapshots have displayed a bug wrt gnome-keyring,
>> >>namely that passwords don't "register" when entered. This wreaks
>> >>havoc on the GNOME desktop where so many programs rely on
>> >>gnome-keyring.
>> >>[...]
>> According to strace, the "couldn't allocate secure memory..." messages
>> seems to be caused by this:
>>
>> gnome-keyring-daemon 3820 seterrno_from_nt_status: /cygnus/src/uberbaum/winsup/cygwin/mmap.cc:1399 status 0xC0000061
>>
>> That is coming from mlock() which hasn't changed in months.
>>
>> The status above translates to: STATUS_PRIVILEGE_NOT_HELD and that is
>> coming from NtLockVirtualMemory() .
>>
>> Yaakov or Corinna does any of the above mean anything to you?
>
>As documented in mmap.cc, mlock functionality requires the SE_LOCK_MEMORY
>privilege which only the SYSTEM account holds by default. Mlock is
>unchanged since it has been introduced in 2005.
>
>Having said that, after searching the net for a while I found out that
>the privilege requirement is excessive. In 2005 I stumbled over the
>wrong interpretation of what the VirtualLock function is doing. Not
>even Microsoft guys are immune to that(*), apparently.
>
>I dropped the requirement for the SE_LOCK_MEMORY privilege in CVS so
>every process should be able to call mlock successfully now.
Thanks. As you surmised this had nothing to do with the problem. It
apparently just a random error in a log file from gnome-keyring-daemon.
The real problem seemed to be a change introduced after 1.7.9 which
subtly broke the handling of signals during I/O. That should be fixed
in the latest snapshot but, like so much of what I've worked on in Cygwin
lately, it touched a fundamental part of the code. I wish I hadn't had
to make this change just before 1.7.10 but, in theory, it should make
it possible for a signal handler to be caught in a thread - that's a first
for Cygwin and it's something I've been meaning to get to for a while.
This isn't perfect though and I hope that doesn't mean that I've
introduced other corner case problems.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -