Conference bulova::decw_jan-89_to_nov-90

3564.0. "ACCVIO from DWTFETCHWIDGET" by BLKPUD::THOMASA (Wow I,ve got a colour ....) Thu Nov 01 1990 11:49

Hi all,
	A customer of mine has a UIL file which he has successfully compiled --
he then starts his application program, up to now all has been ok, but now
he says that after adding more than a certain number of widgets to  his 
existing UIL file,recompiling then re-running his executable -- the  call in 
his code to DWTFetchWidget starts access violating all of a sudden !  


from the PC returned and using anal/system I have tracked down the access 
violation to within the routine

XtManageChildren  see line marked with ****** below



$1$dua1:[v53.decw$libs.dwtlib.lis]MANAGE.LIS at line  7036 
 
void XtManageChildren(children, num_children)
    WidgetList  children;
    Cardinal    num_children;
{
    register CompositeWidget    parent;
    register Widget		child;
    register Cardinal		num_unique_children, i;
	     Cardinal		num_to_map = 0;
	     XtWidgetProc	change_managed;
    register WidgetList		unique_children;
	     Widget		cache[MAXCHILDREN];
	     Widget		cache[100];
	     Bool		parent_realized, map_individually;
	     int		parent_realized, map_individually;

    if (num_children == 0) return;
    if (children[0] == NULL) {
    if (children[0] == 0) {
	XtWarningMsg("invalidChild","xtManageChildren","XtToolkitError",
         "null child passed to XtManageChildren",
	 (String *)NULL, (Cardinal *)NULL);
	 (String *)0, (Cardinal *)0);
	return;
    } 

    parent = (CompositeWidget) children[0]->core.parent;   
    if (parent->core.being_destroyed) return;      **************
.
.
.
.
.



********** this line access violates


reason mask =01 psl =03C00000


Q: What could he of done in his UIL file to cause this to happen ?

Q: Is there a limit on the number of widgets you may load with a single    
   DwtFetchWidget call ?

Q: What should be in children[0]->core.parent -- why might it return an invalid
   value from the UIL which causes :-
 
	if (parent->core.being_destroyed) to access violate ???


		Thanks 

			Andy

Problems with fetchwidget usually indicate a corrupt uil file.  This 
usually occurs when the attachments for an ADB are out of order, but 
circular references and some other uil errors can cause it.  The 
compiler does not signal any errors and just generates a bad uid file.

Try chopping out the new uil stuff until the culprit is identified.

What's the address of the accvio?  The address  - core.parent will 
give you what is in children[0].  Sounds like it is bogus.

Bruce

HI,
	RE: .1 

The stack dump:-

%SYSTEM-F-FACCVIO access violation, reason mask=01.virtual address=656C6876,
PC=00191A65,PSL=03C00000
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name	routine name	line 	rel PC		abs PC
					00191A65	00191A65
					00191CB6	00191CB6





HERE THE PC=0191A65 -- The customer put a lib$wait in his code just before the 
call to DWTFetchWidget -- while his code was "waiting" from another terminal 
I told the customer to do :-   

:-}


$ ANAL/SYS
SDA> SHOW SUMM
SDA> SET PROC/INDEX=nn
SDA> EX IAC$GL_IMAGE_LIST
SDA> EX @.:@.+60

      repeated until DECW$DWTLIBSHR  was found -- noted virtual base address 
of this image 

:-o

using this I did :-

	pc - base_address

	00191A65-0011C600 = 75465 (hex)


						base 		end
	use decw$dwtlibshr.map routine MANAGE  000751BC      00075706


	75465-751BC = 2A9  -- this gives us macro instructions in .lis file
	which points to C code I highlighted

	I have used this method before to correctly track down access violations
,so I am 80% confident I have the right line this time --  always open to
correction though :-)


		Thanks 

			Andy

656C6876 is pretty unlikely as an address, but is "vhle" in ascii.  
By my count being_destroyed is offset 16 
from the start of the widget, giving 656C6866 or "fhle" do either of 
those strings ring any bells?

I'd still suspect an unreported UIL error.

We've also seen this with a customer who does lots of 
XtUnrealizeWidget's and then refetches them later, possibly reusing 
stale memory or who knows what.

Bruce