[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Program occasionally crashes on startup due to GNUstepDefaults.lck e
From: |
Wolfgang Lux |
Subject: |
Re: Program occasionally crashes on startup due to GNUstepDefaults.lck error |
Date: |
Fri, 16 Jun 2017 11:48:12 +0200 |
> Am 14.06.2017 um 22:29 schrieb Lobron, David <dlobron@akamai.com>:
>
> Hello GNUstep people,
>
> I'm debugging an occasional crash that we've observed on machines that run 20
> instances of a GNUstep-based program. The crash does not occur often, and I
> can't reproduce it on demand, but when it does occur, we see a message like
> this:
>
> mapmaker_7.exe: Uncaught exception NSGenericException, reason: Unable to get
> attributes of lock file we made at
> /root/GNUstep/Defaults/.lck/.GNUstepDefaults.lck
>
> Since the lock file path is absolute, I suspect the problem here is
> contention among the various processes for the same file if two or more of
> them are starting up at exactly the same time. However, I would expect a
> lock file to be impervious to multiple readers. Maybe there is a non-atomic
> operation happening here. I searched the code for "GNUstepDefaults.lck", but
> I did find it there. The /root/GNUstep/Defaults/.lck is normally empty, so
> it seems like this is a transient file.
>
> Does anyone know if there's a recommended way to handle this? Is it a known
> issue?
Sort of. I've seen many issues revolving around GNUstepDefaults.lck in the past
here.
However, looking at the code I'm afraid the reason is simply that the
NSDistributedLock implementation is broken (and apparently is so for quite some
time). :-(
The problem is that the code of NSDistributedLock was changed to use
-[NSFileManager
createDirectoryAtPath:withIntermediateDirectories:attributes:error:] with the
second argument set to YES so that it would create intermediate directories.
However, that means that this method returns YES regardless of whether the new
directory already exists or not. I think changing the parameter to NO should
fix your (and everyone else's) issue.
Wolfgang