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
