Submitted by Anonymous on Thu, 03/15/2001 - 22:10. Developers
We have a situation, which is repeatable about 10% of the time where a call to XtSetSensitive(myWidget, False) will lock up the application down in the bowells of X. I am convinced this is happening b/c of some other call I have made far away from this call but even when I run the application with X running synchronously, when I die I die at the same XtSetSensitive call. Any ideas? The fact that this is not reproducable every time has me stumped. Any ideas of what else I can try?
I placed this XtSetSensitive call into our code b/c we had been getting an XError with SetInputFocus BadMatch.
Any help here is valued. If you wish to respond directly, please email at mhaas@sofamordanek.com
Is it actually the server hanging or the application hanging? There`s a big difference. The former should never happen; the latter should never happen in a perfect world, but can.
And do you mean that the bug repeats or that it is reproducible with the same actions on different runs of the application?
You are right to try to debug this while running synchronously. You get more accurate stack traces.
Note that XtSetSensitive() shouldn`t affect a protocol error for SetInputFocus because the window would already have been viewable.
I wonder, though, exactly what you are doing that could have led to that protocol request. When changing focus within Xm, you should be using XmProcessTraversal(). Are you perhaps making Xlib or Xt calls directly?
Another potential problem is in using widgets which have already been destroyed. See http//www.motifzone.com/tmd/tmd_tip_archive.html#object_destroy for a tip on this.
In this particular case, the Application itself hangs and not the XServer. That is, I still have the option to kill the process. But we have seen it often where a poor call such as accessing a NULL widget will in fact hang the XServer and not simply the application. We tend to blame this on Irix as we are temporary constrained to using Irix 6.3 w/ many-a-patches. This, too, will be remedied.
Yes, I intended to say that the bug is reproducable about 10% of the time. I stop the application, restart and 10% of the time the problem will rear its ugly face.
When I set the XmNtraversalOn resource to False for the widgets in question, and run the XServer synchronously, I am unable to reproduce the problem (40+ trials) but under extreme conditions I can still get the XError with the BadMatch on the SetInputFocus. I do not directly call any traversal routines or focus routines; these are all biproducts of other Xevents such as combination box list popdowns etc. I had implemented the XtSetSensitive call b/c during a change in state, when the combination box and its list would automatically by popped down, certain button presses at the right time on this list or combination box text field would generate the SetInputFocus XError. By disabling all button presses with the XtSetSensitive I hoped this problem would be skirted.
Also, I am not ever directly destroying widgets until the end of the application run, in the destructors. I wonder whether or not a combination box destroys/recreates its list every time and if that could cause the issue.
Is there a way to simply ignore an XError and skip the request and continue on like nothing ever happened? I know we could set an X error handler and catch it but that in and of itself does not seem to help us.
Thanks for your responses as I desperately want to find the answer to these issues.