Re: lock issues - again

[Riccardo Mottola]

Hi,


On 11/24/16 07:52, Fred Kiefer wrote:
> As you probably know this message comes from the update method on NSMenu. There 
> we validate all menu entries to decide whether the entry should be active or 
> not. This specifically comes from a menu named „Windows“, most likely our 
> windows menu, where all he active windows are listed. But NSMenu is only 
> relevant as it catches the exception

That makes sense: the Windows menu is the only "dynamic" menu. The 
application is single-threaded (it will spawn threads, but only after 
some kind of action, not on startup) so GNUstep is fighting against itself.

> that gets thrown by NSDistributedLock. The best you could do is add a debugger 
> breakpoint in the HANDLING code and print out the stack from there. As far as I 
> remember there is also a way to print the stack of an exception directly from 
> code, maybe Richard could help here.
>
> That way you could see where and why the exception actually happens. But maybe 
> you and Richard are already aware of that. in that case just ignore my mail.

On this machine I have seen this error only very rarely, so I cannot 
easily reproduce and get a stacktrace.
Adding a stacktrace printout on lock breakage would be quite useful, I 
am not aware of how to do that.
It could also help understand why on certain setups GWorkspace daemons 
have the lock issues: I have no idea on how to get a trace of a child 
process started by an application.
Perhaps these lock issues have a common root that we are not seeing 
right now. Besides that they are annoying, I think we do have a bug: you 
can't reproduce it and I have setups where it is usually smooth, but on 
several of my systems I have the issue. I wonder if others have too. 
Perhaps it depends on the fact that I use GUI apps more than others (not 
saying it is a GUI issue, just that GUI stresses things more perhaps).


Riccardo