Re: fcntl always fails to delete lock file, and PID is always -6464

From: Garrett Cooper <gcooper_at_FreeBSD.org>
Date: Sun, 3 Oct 2010 22:08:31 -0700
On Sun, Oct 3, 2010 at 10:05 PM, Garrett Cooper <gcooper_at_freebsd.org> wrote:
> On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO <daichi_at_ongs.co.jp> wrote:
>> It looks very strange. fcntl() always fails to delete lock file
>> and command.l_pid is always -6464. This issue is disclosed in
>> porting Google's Japanese input system called "mozc".
>>
>>  details follow:
>>    http://code.google.com/p/mozc/issues/detail?id=40
>>
>> % uname -a
>> FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010     root_at_parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL  amd64
>> %
>>
>> My home directory on NFS server.  Does anyone have any ideas?
>
>
>    I see some bad assumptions in the code:
>
>    const int result = ::fcntl(*fd, F_SETLK, &command);
>    if (-1 == result) {  // failed
>      ::close(*fd);
>      LOG(WARNING) << "already locked";
>      return false;   // another server is already running
>    }
>
>    If the developer actually coded to POSIX expectations, he/she
> would be checking for EACCES/EAGAIN; there are a myriad of other
> issues that might be occurring with the software, as per my copy of
> SUSv4 (see the ERRORS section of fcntl). I would print out the
> strerror for that case.
>    Providing a backtrace of the application's execution and the
> architecture and what version of FreeBSD you're using would be
> helpful.
> Thanks,
> -Garrett
>
> PS Quickly looking over this code, it has portability issues assuming
> that all Unix based OSes (that aren't under some Mac OSX guard) are
> Linux, based on the number of /proc filesystem opens and reads I see
> in the code.

Sorry... missed some of the details in spite of the trees (FreeBSD
version in particular).
Thanks,
-Garrett
Received on Mon Oct 04 2010 - 03:08:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC