| This particular CVR is used when mcc_malloc can't supply the
requested block of memory. I believe mcc_malloc is allocating
from a pool of memory it establishes. This is NOT VMS dynamic memory.
I also believe that both the CVR and the mcc memory routines will
be documented in the next version of the SRM.
I can't tell why the customer is running out of memory to allocate. They
should, of course, be freeing what they allocate as possible.
I'll see if a QAR is in order.
Ruth K.
|
|
Hello,
Some more information on my customer pbs explained in this note:
"Here are some facts about our AM and the error we have:
The error occours when we are making a class-table in a function called
from the begin_directive. When calling the mcc_dict_get_sub_pairs we
get the status MCC_S_ALLOC. This is only happenning when doing
DEREGISTER. Everything are working fine when doing a SHOW. The structure
and the function calls are exactly the same for the DEREGISTER directive
as for the SHOW directive:
mcc_apbx__dir_show/deregister /* Seperate modules, but identical */
begin_directive /* \
mcc_apbx_init_directive /* - These three functions are common!
mcc_apbx_class_table /* /
When using the TEST BED, the DEREGISTER is working well. The manual says
that if the AM is working with the TEST BED and not with the PM, this
can be because of inconsistency between the dictionary and the vector
file. Can this be true?
I have also measured the Working Set Size when running the AM. I've
noticed that when entering the AM, the DECmcc already have used much
more memory when doing a DEREGISTER than doing a SHOW. When our problem
occurs we have nearly began to run the AM and have not used much memory
yet. Our SHOW directive uses totally much more memory than a DEREGISTER
and the SHOW works fine, so if this is a memory problem, there has to be
something wrong. The same code used on version 1.1 of DECmcc is working
very well, and if the DECmcc 1.2 uses more memory it should only be fair
that we still can use the same amount of memory in the AM as before.
Can there be parameters concerning memory in the DECmcc V1.2 which are
set to wrong values?
We also have problems with the mcc_dict_get_sub_pairs when using the
REGISTER directive, but in another way. The first call is working well,
but on the second one we get an access-violation. I have checked the
input parameters and they look correct.
If we don't use the class-table function (it's not necessarry in all
cases) we get problems with the mcc_dict_translate_name routine further
down in the code when doing a REGISTER. It always returns the status
MCC_S_NO_SUCH_CIPAIR. This is also working well with DECmcc V1.1.
We are also using the mcc_dict_get_sub_pairs and mcc_dict_translate_name
routines in other functions without any problems.
Results of our memory measurements:
WORKING SET SIZE: V1.2 V1.1
DEREG DEREG* SHOW DEREG
--------------------- -------
WITH FCL:
Entering AM 5856 4806 4033 5279
Before Call to get_sub_pairs 6456 4956 4183 5579
WITH TEST BED:
Entering AM 3548 3248 ....
Before Call to get_sub_pairs 3998 3548 ....
*) Optimized to use less memory, but still I got the error!
Our VMS quotas:
Process Quotas:
Account name: NMC
CPU limit: Infinite Direct I/O limit: 400
Buffered I/O byte count quota: 80000 Buffered I/O limit: 150
Timer queue entry quota: 150 Open file quota: 200
Paging file quota: 79045 Subprocess quota: 16
Default page fault cluster: 64 AST quota: 4094
Enqueue quota: 2000 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0
Process Dynamic Memory Area
Current Size (bytes) 25600 Current Total Size (pages) 50
Free Space (bytes) 13952 Space in Use (bytes) 11648
Size of Largest Block 13632 Size of Smallest Block 8
Number of Free Blocks 10 Free Blocks LEQU 32 Bytes 6
System Memory Resources on 18-DEC-1991 09:46:43.25
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (96.00Mb) 196608 16127 166584 13897
Slot Usage (slots): Total Free Resident Swapped
Process Entry Slots 350 165 148 37
Balance Set Slots 315 143 146 26
Fixed-Size Pool Areas (packets): Total Free In Use Size
Small Packet (SRP) List 6843 961 5882 112
I/O Request Packet (IRP) List 5533 1374 4159 176
Large Packet (LRP) List 258 66 192 1648
Dynamic Memory Usage (bytes): Total Free In Use Largest
Nonpaged Dynamic Memory 2466816 128912 2337904 32928
Paged Dynamic Memory 1871872 442640 1429232 415408
Best Regards
Catherine
|
| RE: .2
> When using the TEST BED, the DEREGISTER is working well. The manual says
> that if the AM is working with the TEST BED and not with the PM, this
> can be because of inconsistency between the dictionary and the vector
> file. Can this be true?
Yes - this *can* be true - but probably not in your case. With TBD, you
hand-build your Call Arguments. FCL and the Iconic Map use the Dictionary
to build the Call Arguments. The problem you might find between the two
types of interfaces is the construction of In-Entity & complex datatypes.
With FCL try dumping the call arguments:
$ define MCC_FCL_PM_LOG 8
and compare this with the dump of the call arguments you generate with TBD.
Also, with TBD, are you doing a Call Access or Call Function? See below
about the Registration FM
> Can there be parameters concerning memory in the DECmcc V1.2 which are
> set to wrong values?
You could try increasing the stack size ...
$ define MCC_STACK_EXTENSION
This parameter is measured in Hex pages (of 512 bytes):
a value of 40 = 64 pages (dec) = 32k bytes of stack
80 = 128 pages (dec) = 64k bytes of stack
> Our VMS quotas:
> :
> :
These look good - and you obviously have plenty of memory (96MB)
You should try monitoring the running DECmcc process and watch the
virtual page count parameter; check this value with SYSGEN:
$ mcr sysgen show virtualpagecnt
This is the maximum amount of memory a process can have. To see how much
your process is currently using; from another window, type:
$ show process/continuous/id=<pid>
and enter the process id (pid) of the process running DECmcc. You get
the MCC_S_ALLOC (ie, Insufficent Virtual Memory) error when the 'Virtual
Pages' field exceeds the VIRTUALPAGECNT sysgen parameter. I suspect that
you aren't exceeding this, and something else is going wrong.
Also, I believe that the Registration FM executes your Register & Deregister
directives first, then calls your AM specific entry points (if you have
defined them). Something could be happening in there.
Hope this helps -- please post any more information you have.
Keith
|