Many thanks for this fix, Wolfgang and Richard! --David
> On Jun 17, 2017, at 2:04 AM, Richard Frith-Macdonald > <[email protected]> wrote: > >> >> On 16 Jun 2017, at 10:48, Wolfgang Lux <[email protected]> wrote: >> >> >>> Am 14.06.2017 um 22:29 schrieb Lobron, David <[email protected]>: >>> >>> 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. > > Thanks a lot for that Wolfgang, I've spent days trying to figure out why the > user defaults locks were occasionally failing, looking in completely the > wrong area (threading mostly)' and never considering it might be something as > basic as that. It's great that you spotted the cause of the problem. > I have changed the NSDistributedLock code (github) to use O/S level functions > to create the lock directory, to be sure that if a directory already exists > we see the creation attempt as failing rather than succeeding. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
