Conference bulova::decw_jan-89_to_nov-90

>
>
>        (Decwindows Vax 3500 running VMS 5.0)
>
>        Hi ... I am receiving a nasty crash in my application and the crash
>        is taking place deep in the heart of X. I tried X_debug but that yeilded
>        nothing. Would you have any further suggestions as how to get closer 
>        to this bug?
>

	Are you REALLY running VMS 5.0?  My first sugestion would be to run a
more recent version of VMS, like 5.3!

Mark

Mark
	Actually I'm running VMS 5.1 with DEC windows... I think you are 
	incorrect about your solution to my problem.

	Any other takers

	Much appreciated

Are you doing any XGetWindowProperty calls in your code?  If so, for
which properties?  Try putting

		XSynchronize (dpy, 1);

at the beginning of your program and see if this helps you narrow down
the call.

I suspect the GetProperty request has bad parameters.

-steve-

	hi DECWIN::KLEIN

	Thanx for the consideration... 

	The complexity of this bug is just what you said except I am not making
	the call to X_GetProperty... DecWindows is. All I am doing is a 
	SetArg then a SetValues to a user defined widget (which is done in an 
	AST that is constantly strobing every 10 secs)... when I try to do other
	events like pulldown a menu while the AST is strobing I get the crash
	on any events that I promote while the AST is strobing. Somehow X is
	being set up to crash at a later period.

	I've got the two lines of code that are causing this but all looks 
	ok..... I know all isn't ok but it looks ok.

	I also tried    
		XSynchronize (XtDisplay(toplevel_widget), 1)
	and you already saw the results of that.

	Could it be the way the user defined widget is set up wrong??
	Have you encountered anything close to this set up?


	Much Appreciated

The call to XGetProperty from AST level is not a good idea.
Since you are also using the toolkit, the event queue should be
left to the toolkit to control, and executing a request that expects a reply
from AST level is a complexity that is probably not handled well.
I know that XLib is supposed to be AST tolerant, but there are still problems.

I suggest that, since you are using the toolkit, you also use XtAddTimeout
instead of calling XLib from AST level.

I question why you are strobing the property anyway, since PropertyNotify
events exist specifically to avoid that need.

-steve-

	As I stated before the only two calls I am making are a XtSetArg and
	XtSetValues which are called in an AST that is triggered from the 
	X event queue every 10 secs. Now this will run forever fine when my
	menus come up and all is well... But... After say 30 seconds I try to
	pulldown a menu from my application while this AST is updating a part
	of my display I get the crash. The crash is provoked by a later X event
	but is being set up by the XtSetArg and XtSetValues. If I take these two
	Xtoolkit calls out the application is ok but I need the two lines for my
	application. Just want to provide detailed info so you know exactly 
	what is happening.

	What are the problems with Xlib and AST's then even though it is AST
	tolerant cause I got a bunch of them running at the same time?

	Also what will XtAddTimeout do for me?

	As to your question... I don't know why Decwindows would be referring to
	X_GetProperty. 

	Also your reference to Xlib and Ast level events...

	I am using XtAddInput to route the execution of the AST onto the 
	X event queue. VMS sets the efn that actually provokes the triggering
	of the routine tied to the efn. Does this scenario look like it may
	posess any frailties

	Much appreciated

    Calling anything Xt... in an AST routine is not supported.  It's as
    simple as that.  What the AST is supposed to do is call the $SETEF
    system service to set the input flag that tells the toolkit to call
    the input callback proc later.  AST routines should only modify
    interlocked data structures.  The toolkit data structures are not
    interlocked.
    
    It is the XtInputCallbackProc client_proc that is supposed to call
    Xt... routines.  It is not executed as an AST routine.
    
    The mask bit is PropertyChangeMask and you add it to your application
    with XtAddEventHandler or XtAddRawEventHandler.
    
    Timer events are correctly handled by XtAppAddTimeout.  So if you are
    not writing an example program, you'd be far better off using
    XtAppAddTimeout as a previous reply indicated.

	re .8

	It should be ok to call Xt routines thru a routine that is triggered
	when VMS sets a certain efn after a certain amount of time provided
	the routine is routed thru the X event queue using XtAddInput which is
	what I am using. 

	Could we coalesce our concepts on what an AST routine is and what is
	should or shouldn't do? My application has been running fine with a
	the small exception I encountered using 4 to 6 routines of the above
	nature.

	I guess I want to know... is the nature of which I am attaching
	routines to with efns and executing them called AST routines?

	I'd appreciate if you could fix me up here on what the standard
	AST routine definition is cause I have seen many ways of setting 
	things up.

Projects,

(By the way, who ARE you?)

XtAddTimeout will do the timer-based wakeup that you are doing yourself
through the use of XtAddInput and $SETIMR.  XtAddTimeout is preferable,
since it is portable and much simpler.

XtAddInput does NOT add events to the X event queue.  It only merges
a callback into the Xt main loop.  There is a distinction.  Other
actions in the XtMainLoop are workProcs and X events.  You cannot use
XtAddInput or XtAddTimeout unless you are using the toolkit and its
XtMainLoop (or equivalent).  Are you using XtMainLoop?

You should never call Xt from AST level.  Period.
I am confused by your statements in .6 and .7.  First you say "... the only
calls I am making are ... XtSetValues which are called in an AST ...", and
then in .7 you say "I am using XtAddInput to route the execution of the
AST onto the X event queue."  Are you or are you not calling Xt* from AST
level?

Once the AST has been routed through XtAddInput to non-AST level, the
work is no longer being done at AST level.  XtAddTimeout callbacks are
not done at AST level, therefore it is always safe to call Xt from within
an XtAddTimeout callback..

By the way, I don't think that XtSetArg is a routine.  It is just a macro
that helps (?) build a simple argument list.  I never use it.

While your "AST" routine is executing (assuming that it isn't really an
AST anymore but is simply the XtAddInput callback), any ButtonPress event
that would cause a menu to be pulled down would not be dispatched until
your "AST" routine returns.  The execution of events and XtAddInput callbacks
are mutually exclusive and serial.  So this just makes it even more puzzling.

Suppose you just post your AST routine sources here and let's take a look.
It ought to be a simple $SETEF/return.

And do you have sources to the user_defined widget?  If so, you might
want to trace the SetValues operation to see what property calls are
being made.  Is the widget "trustworthy" or might there be a bug there?

-steve-

	-steve-


	I'm a programmer

	Thanks for the detailed reply... it made alot of sense and I believe
	the way I am doing things is sort of the same thing that XtAddTimeout
	was made to do. 

	Anyway I found the problem. It was a a memory allocation problem
	inside the user defined widget that posted an array of symptoms one
	of which I displayed earlier. The symptoms depended upon how frequent 
	the ast routine (or XtAddInput routine) utilized the user defined widget.


	Thanks

       
       
       	Can we please have a more descriptive title for this topic??
       "Big Bug" doesn't tell anyone anything.
       
       							mike

>> 	 Can we please have a more descriptive title for this topic??
>>       "Big Bug" doesn't tell anyone anything.

How about "Programmer Error".

-steve-