discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lock issues - again


From: Fred Kiefer
Subject: Re: lock issues - again
Date: Thu, 24 Nov 2016 17:33:15 +0100

> Am 24.11.2016 um 10:24 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> 
> On 11/24/16 07:52, Fred Kiefer wrote:
> 
>> 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.
> 
> 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).

I had to look it up, but printing a stack trace is quite easy in GNUstep. Just 
call [[exception _callStack] description] in an NSLog statement.
You may add this to the handling clause in NSMenu and run your application as 
often as possible to try to get the issue.
You could instead add this call in NSDistributedLock where the exception gets 
created. That way you would get all relevant cases.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]