[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

272.0. "How to delete a repository?" by CLUSTA::YANG () Tue Aug 21 1990 21:21

    I am implementing MCC MIR in our prototype work. I have two questions
    related to repository creation/deletion.
    1) When a MCC_MIR_CREATE_REPOSITORY call is made, a directory
    location specification is required, I passed the specification with a
    VMS logical name, then I run my API with the same logical name defined to be
    a different directory location, I expected it should create a new
    repository for me, however, it returns me a "repository already exists"
    error message. It seems MCC recognizes the instance repository name was
    already created, so it rejects the second call regardless of a
    different location being passed. Then, my confusion is that why the
    call needs the directory location specification as an argument?
    
    2) Once I created a repository, I could not find any DELETE_REPOSITORY
    routine to delete it in MCC manual. Can somebody tell me how to delete
    a repository?
    
    Yah-Kong,
T.RTitleUserPersonal
Name		DateLines
272.1In addition: ACCESS VIOLATION on MCC_MIR_DEL_INSTANCEBYBLOS::TAMERThu Aug 23 1990 16:3442
The following call is access violating from the MCC director:

mcccode = MCC_MIR_DEL_INSTANCE(                    &instance_rid,
                                                   p_entity,
                                                   MCC_K_NULL_PTR,
                                                   &instance_key,
                                                   MCC_K_NULL_PTR);


However, the instance is deleted because we can create it afterwards.

What is puzzling is that this same call (same code) of "MCC_MIR_DEL_INSTANCE" 
works when called from a program linking with callable MCC.

Any clues ?

Phil

This is a sample debugger session:


MCC> create server p1 image=p1.exe
%DEBUG-I-DYNIMGSET, setting image MCC_TP_AM
%DEBUG-I-DYNMODSET, setting module MCC_TP_AM_INITIALIZATION
DBG> g
Routine <mcc_tp_am__create>
%DEBUG-I-DYNMODSET, setting module MCC_TP_AM_SVC_ENTRY
DBG> g
server p1
AT 23-AUG-1990 12:10:02


Server instance was successfully created in the management database
MCC> delete server p1
Routine <mcc_tp_am__delete>
DBG> g
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=7FE75400, PC
=00053262, PSL=0BC00004
%DEBUG-E-LASTCHANCE, stack exception handlers lost, re-initializing stack
%DEBUG-I-EXITSTATUS, is '%NONAME-W-NORMAL, normal successful completion'
DBG> exit
272.2See 278.1TOOK::GUERTINWherever you go, there you are.Mon Aug 27 1990 17:2412
    RE:.0
    
       See reply to note 278 (278.1)
    
    RE:.1
    
       I am guessing that you have exceeded your stack size.  Are you
    creating threads?  The delete instance command is very stack intensive,
    because it recursively walks down the instance hierarchy and deletes
    child entities as well.  Do you have a very large instance hierarchy?
    
    -Matt.
272.3PETE::BURGESSMon Aug 27 1990 18:0048


Here are my thoughts and observations:


Stack overflow problems are of two types:
1) mcc_thread_create will create a thread with a limited stack
   size (default = 64 pages) plus a few  guard pages.  
   The default value may be controlled
   by defining the logical mcc_thread_stack_size to <num-pages>

   The thread stack is allocated from p0 heap 

   
2) The main thread uses the vms controlled stack in p1 space.
    This stack may from until the program exceeds its virtual address space.

Case 1 is far more frequent than case 2.


%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=7FE75400, PC
=00053262, PSL=0BC00004
%DEBUG-E-LASTCHANCE, stack exception handlers lost, re-initializing stack
%DEBUG-I-EXITSTATUS, is '%NONAME-W-NORMAL, normal successful completion'


The pc of 53262 is not likely to be within the kernel/mir code.
Of central interest in debugging this problem is 
	what is the macro instruction at 53262?
         and the relevent register values?

         What image is mapped to this virtual address region?

The va is within p1 space not p0 space.  Thus the problem is NOT a
case 1 stack overflow problem.

PSL with bit-2 set => write/modify operation on 7fe75400
What's illegal about this va?


Generally the last chance handler is invoked when the 
user stack is corrupted.  Symptom could also occur if
some code clobbered a stack frame and later signalled a condition.

It's to use that four letter word -/debug

Pete