[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

1156.0. "ACCVIO and Iconic map" by DGOSW0::GUESDON () Mon Jun 17 1991 14:19

    We have again some problems with the Iconic map PM:
    
    When we do a REGISTER command from the FCL PM (with the IN DOMAIN
    qualifier), everything works fine.
    
    When we do the same with the Iconic interface, we have an access
    violation message, in the first instruction of the routine mcc_once
    (called by mcc_mir_read_uid, called by dap_def_select, etc. until 
    mcc_dns_write_attr_data).
    
    I don't think that the problem is due to the mcc_once routine... I
    remarked that the User Stack was heavily used.
    
    How can I know the initial size of the user stack allocated by the
    MCC_MAIN program, and do you think that it may be the cause of the
    problem ?
    
    Michel.

T.R	Title	User	Personal Name	Date	Lines
1156.1		TOOK::F_MESSINGER		`Mon Jun 17 1991 15:19`	17
	When we do a REGISTER command from the FCL PM (with the IN DOMAIN qualifier), everything works fine. When we do the same with the Iconic interface, we have an access violation message, in the first instruction of the routine mcc_once (called by mcc_mir_read_uid, called by dap_def_select, etc. until mcc_dns_write_attr_data). >>What are you registering? I don't think that the problem is due to the mcc_once routine... I remarked that the User Stack was heavily used. >How did you determine this? I think our mcc thread stack size is 128 pages. >What user actions lead up to the acc-vio.
1156.2	Sorry I forgot it..	DGOSW0::GUESDON		`Mon Jun 17 1991 16:45`	23
	Sorry, I forgot some infos: >>What are you registering? I'm registering a specific entity for which we have written a new AM. >How did you determine this? With the VMS debugger. I stepped to the instruction which originates the ACCVIO error, and did a SHOW STACK debug command. I don't know how I can calculate the size of the stack, but I took the most recent and the oldest stack frames. That gives me some idea: Stack frame 0 address : 1D386C Stack frame 42 address : 1E69B4 That gives me a difference of 78152 (around 152 pages) Is it correct ? Michel.
1156.3		TOOK::F_MESSINGER		`Mon Jun 17 1991 19:19`	2
	>What user actions lead up to the acc-vio.
1156.4	stack size	TOOK::CALLANDER	Jill Callander DTN 226-5316	`Mon Jun 17 1991 19:45`	20
	It is possible that you are overrunning the stack, and no there aren't any nice messages for it. 1) do you set up most routines with alot of variables on the stack, or do you do a lot of dynamic allocation? 2) is your code "deep" (losts of routines calling dow into alot of toehr routines)? 3) are you using the design framework? There is a logical (at least I believe it still exists) called MCC_STACK_SIZE define this to be 80 and see what happens when you try the same command from the fcl. Does it accvio? (BTW I picked 80 out ofthe hat, FCL doesn't use as much stack as the IM PM so I picked a smaller number thatn the 128 stated by Fred). This is a non-conclusive test, but if you do get the same results we might want to get Matt to give you some hints on how to test what you are using for stack size, and have you review you code for unused and duplicate stack variables.
1156.5	We tried the MCC_STACK_SIZE	DGOSW0::GUESDON		`Fri Jun 21 1991 12:33`	11
	We tried to set MCC_STACK_SIZE to 80 before using the FCL PM, and it worked perfectly... (We tried also to set the MCC_THREAD_STACK_SIZE). Are you sure of the name of this logical: it seems to have no influence. Is the stack size set to a maximum of 128, or is there a way to increase this size to see if the problem is at this level ? Thank you Michel.
1156.6	mcc_thread_stack_size?	TOOK::CALLANDER	Jill Callander DTN 226-5316	`Mon Jul 08 1991 21:15`	7
	I just reread the previous answers to this note and didn't see a references to an mcc_thread_stack_size, maybe I missed it. mcc_stack_size is the only one I know of. jill (oh mcc_stack_size resets the thread stack size used when a new thread is created)
1156.7	stack size is fixed at 128 pages	POLE::LEMMON		`Mon Jul 15 1991 20:26`	8
	The Iconic Map does a mcc_thread_create() with the stack size set to 128. It can't be reset by logical or user control. If this problem has not been resolved (hopefully it has been by now) I can get you a copy of the iconic map with a larger stack size to see if this is the problem. /Jim
1156.8	Our problem still exists	DGOSW0::GUESDON		`Wed Jul 17 1991 15:19`	10
	No... The problem has not yet been solved ! So we have to register entities with the FCL PM, and then insert them in the appropriate domain. It is a solution for now, because our AM is only a prototype, but we'll have to find a solution ... Can you tell me where I can find the iconic map with a larger stack size ? Thank you.
1156.9	Can somebody help ?	DGOSW0::GUESDON		`Sat Aug 03 1991 09:06`	1

1156.10	Version number?	POLE::D_WONG	David Wong @LKG 2-2	`Wed Aug 07 1991 13:29`	10
	Michel, Would you tell me what version of DECmcc or Iconic map PM you are running? As soon as I have that answer, I will build you an iconic map with a larger stack size for you to test. Do you think 256 pages would be enough? If that fixes your problem, we may use logical to allow users to specify the stacksize. david.
1156.11	DECmcc 1.1	DGOSW0::GUESDON		`Wed Aug 07 1991 16:12`	9
	We're using DECmcc 1.1 SSB ... I don't know if 256 pages will be enough... In fact I don't know if the stack size is really the problem. With this new version of the Iconic map, we could be sure. Thank you. Michel.