| Title: | NAS Message Queuing Bus |
| Notice: | KITS/DOC, see 4.*; Entering QARs, see 9.1; Register in 10 |
| Moderator: | PAMSRC::MARCUS EN |
| Created: | Wed Feb 27 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2898 |
| Total number of notes: | 12363 |
Hello,
I have a customer running DecmessagQ 3.2.0 on NT 3.51 sp 5. They
seem to have amemory leak using cls. The customer is going to send me
sample code which should reproduce this problem. She has used an
example that came with decmessageq to re-create the memory problem.
Before I elevate this to engineering I was wondering if anyone has seen
this before. As soon as I get the sample code I will add it to this
note, Just thought someone may have already seen this...
Thanks in advance.
Paul brady
DTN 592-4168
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2852.1 | sample code | CSC32::P_BRADY | Thu Apr 17 1997 21:20 | 273 | |
Here is the sample code from my customer
/** ....................... **/
/** C library include files **/
/** ....................... **/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
/** ......................... **/
/** DECmessageQ include files **/
/** ......................... **/
#include "p_entry.h"
#include "p_return.h"
#include "p_symbol.h"
/** ....................... **/
/** Constants **/
/** ....................... **/
#define MAX_MESSAGE_SIZE 100
/** ....................... **/
/** Function Forwards **//*
/** ....................... **/
int32 TheAttach( q_address *q_addr,
int32 q_type);
int32 ThePut( q_address *q_addr );
int32 TheGet(q_address que_to_get);
void TheExit( );
long
main( )
{
int32 dmq_status;
q_address my_primary_queue;
q_address my_secondary_queue;
q_address queue_to_talk;
printf( "\nTesting program started...\n\n" );
for (;;)
{
/* Attach to DECmessageQ */
if ( TheAttach( &my_primary_queue,
PSYM_ATTACH_PQ
) != PAMS__SUCCESS )
exit( 0 );
/* Attach to a secondary queue */
if ( TheAttach( &my_secondary_queue,
PSYM_ATTACH_SQ
) != PAMS__SUCCESS )
exit( 0 );
/* Set up the queue to talk to */
queue_to_talk.au.group = my_primary_queue.au.group;
queue_to_talk.au.queue = 8;
/* Put messages to the queue the I want to communicate
with */
dmq_status = ThePut( &queue_to_talk );
/* Get them back */
dmq_status = TheGet(my_secondary_queue);
/* Exit from DECmessageQ */
TheExit();
}
printf( "\nTest complete.\n" );
return( PAMS__SUCCESS );
} /* end of main */
int32
TheAttach( q_address *q_addr,
int32 q_type)
{
int32 attach_mode;
int32 dmq_status;
attach_mode = PSYM_ATTACH_TEMPORARY;
dmq_status = pams_attach_q(
&attach_mode,
q_addr,
&q_type,
0,
0,
(int32 *) 0, /* Use default name space */
(int32 *) 0,
(char *) 0,
(char *) 0,
(char *) 0 );
if ( dmq_status != PAMS__SUCCESS )
{
printf( "Error attaching to a temporary queue, status returned
is: %ld.\n",
dmq_status );
}
return ( dmq_status );
} /* end of TheAttach */
int32
ThePut( q_address *q_addr )
{
int i;
char priority;
char delivery;
char uma;
short msg_class;
short msg_type;
short msg_size;
int32 dmq_status;
int32 timeout;
struct PSB put_psb;
static char *MessageList[] = {
"This is the request packet for the openpath call",
"This is the aux packet for the openpath call"};
/*
** Put the messages in MessageList to the queue passed in
*/
printf( "\n" );
priority = '\0'; /* Regular priority; use 0, NOT '0'
*/
msg_class = msg_type = 0; /* No class or type at the moment
*/
delivery = PDEL_MODE_NN_MEM; /* No Notification and
nonrecoverable */
timeout = 100; /* Wait 10 seconds before giving up
*/
uma = PDEL_UMA_DISCL; /* If can't deliver it, DISCard and
Log */
for ( i = 0; i < 2; i++ )
{
msg_size = (short) strlen( MessageList[i] );
dmq_status = pams_put_msg(
MessageList[i],
&priority,
q_addr, /* passed in */
&msg_class,
&msg_type,
&delivery,
&msg_size,
&timeout,
&put_psb,
&uma,
(q_address *) 0,
(char *) 0,
(char *) 0,
(char *) 0 );
if ( dmq_status == PAMS__SUCCESS )
printf( "Put message:\t%s\n", MessageList[i] );
else
printf( "Error putting message; status returned is: %ld.\n",
dmq_status );
}/*end for */
return ( dmq_status );
} /* end of ThePut */
int32
TheGet(q_address que_to_get)
{
char priority;
short msg_class;
short msg_type;
short msg_area_len;
short msg_data_len;
int32 dmq_status;
int32 *pt_sel_filter;
char msg_area[MAX_MESSAGE_SIZE];
q_address msg_source;
struct PSB get_psb;
short sSelFilter[2];
printf( "\n" );
priority = 0; /* get messages of both high and normal
priorities */
sSelFilter [0] = que_to_get.au.queue; /* Only select messages queued
to my secondary queue */
sSelFilter [1] = PSEL_AQ;
pt_sel_filter = (int32 *)sSelFilter;
msg_area_len = MAX_MESSAGE_SIZE;
dmq_status = PAMS__SUCCESS;
while ( dmq_status == PAMS__SUCCESS )
{
/* Initialize the message area to hold the message */
memset( msg_area, '\0', MAX_MESSAGE_SIZE );
/* Get a message */
dmq_status = pams_get_msg( msg_area,
&priority,
&msg_source,
&msg_class,
&msg_type,
&msg_area_len,
&msg_data_len,
pt_sel_filter,
&get_psb,
(struct show_buffer *) 0,
(int32 *) 0,
(char *) 0,
(char *) 0,
(char *) 0 );
switch ( dmq_status )
{
case PAMS__SUCCESS :
printf( "Got message:\t\"%s\"\n", msg_area );
break;
case PAMS__NOMOREMSG :
/* Status returned when queue is empty */
break;
default :
printf( "Error getting message; status returned is %ld.\n",
dmq_status );
break;
}
}
if ( dmq_status == PAMS__NOMOREMSG )
{
dmq_status = PAMS__SUCCESS;
}
return ( dmq_status );
} /* end of TheGet */
void
TheExit( )
{
int32 dmq_status;
dmq_status = pams_exit();
if ( dmq_status == PAMS__SUCCESS )
printf( "\nExited from DECmessageQ.\n" );
else
printf( "Error exiting; status returned is %ld.\n", dmq_status );
} /* end of TheExit */
This will cause a memory leak which will continue unitl the box
crashes...
Any help would be great.
| |||||
| 2852.2 | DECWET::SIMONICH | Make it look easy | Mon Apr 21 1997 15:25 | 9 | |
I'll try to take a look at it this week. A few more details would be helpful:
o How are they observing the leak?
o How fast does the memory appear to leak?
o Are they running the test locally on the NT box, or remotely on a client
machine? If the app is running remotely, which DECmessageQ client are they
using ( Windows 3.1/95/NT, or UNIX )?
Pat
| |||||
| 2852.3 | CSC32::P_BRADY | Fri Apr 25 1997 15:23 | 3 | ||
I will pass this info on to the customer, they called today looking for
an update. Thank you very much...
| |||||
| 2852.4 | Answer to questions | CSC32::P_BRADY | Fri Apr 25 1997 21:57 | 43 | |
Hello Pat,
Thanks for helping us out with the call. I have a response fromthe
customer.
Here are answers to your questions:
o How are they observing the leak?
We use both PView and Windows NT Performace Monitor. They both
indicate
the virtual bytes going
up when the test program is running. The dmqcls initially uses
appox. 12Mb
of virtual memory.
Several times when it eventually reaches 545Mb, the dmqcls hangs.
However,
one time the dmqcls
hangs when its virtual memory reaches 82 Mb.
o How fast does the memory appear to leak?
I can't tell it leaks at a constant rate. Initially it is doubled
in 5
minutes (from 12Mb to 25Mb).
It goes up to 35Mb in 30 minutes. It would stay at certain level
for a
while, then jumps up
another 10Mb.
o Are they running the test locally on the NT box, or remotely on a
client
machine? If the app is running remotely, which DECmessageQ client
are they
using ( Windows 3.1/95/NT, or UNIX )?
We are running the test locally on the NT box.
You should be able to run the test problem on your machine, and see for
yourself how virtual memory gets eaten up, and finally the dmqcls
hangs.
| |||||
| 2852.5 | XHOST::SJZ | Kick Butt In Your Face Messaging ! | Sat Apr 26 1997 01:42 | 5 | |
using perfmon, as the CLS grows, what is the handle count
and thread count for the dmqcls process ?
_sjz.
| |||||
| 2852.6 | Need CLS version number | DECWET::SIMONICH | Make it look easy | Mon May 05 1997 18:22 | 18 |
I finally got a chance to try your test program. Sorry for being so slow, but
we recently lost one of our engineers which hampers our ability to do product
support.
I was using an NT 3.51 (Service Pack 5) system with the V3.2 DECmessageQ for
Windows NT SSB CD. I ran the program as a local client for approximately 45
minutes, and the CLS didn't appear to have any memory leak. The Virtual Bytes
increased/decreased as the test program attached/detached, but overall the
value was constant. Other parameters like Handle Count and Thread Count behaved
similarly.
Could your customer be using a pre-SSB version of the CLS? Can you get the
CLS version number from them? The CLS on the V3.2 CD is version 3.2.006.
I know the CLS had a memory leak early on in V3.2 development, but it was
fixed prior to SSB.
Pat
| |||||
| 2852.7 | CSC32::P_BRADY | Mon May 05 1997 19:16 | 12 | ||
I will forward this on to the customer.
Thanks again for the help...
I will let you know what I found out.
P.S.
These are the answers to you second questions.
Within seconds, the thread count went up to 8 from 2, and the handle
count went up to 80 from 21.
Maryann
| |||||
| 2852.8 | CSC32::P_BRADY | Mon May 05 1997 20:48 | 13 | ||
I asked the customer the question about the version of Decmessage queue
here is the answer.
How do I know if the CLS version is SSB 3.2.006? We have the CD for
V3.2, and does not indicate anywhere if it is SSB CD or the release
version. I looked at the DMQ test program and config program, their
versions are 3.2.32.001 and 3.2.32.002. The Registry also only has
V3.2. (revision is 0)
Please let me know how I can find out the actual CLS version installed
on our system.
Thanks!
Maryann
| |||||
| 2852.9 | DECWET::SIMONICH | Make it look easy | Tue May 06 1997 15:52 | 16 | |
Sounds like you are using a field test CD. The SSB CD says "DECmessageQ for
Windows V3.2". It also has a Digital logo and part number AG-PZLTE-BE.
If your customer is using a field test CD they need to purchase the SSB
version. We aren't providing support for the V3.2 field test kits.
You can determine the CLS version number in two ways:
1. Watch the messages displayed on the Event Watcher. When the CLS start up
it prints a version number message that says
cls, DECmessageQ Client Lib Server, Version 3.2.006
2. Check the dmqlog.log file for the same message.
Pat
| |||||
| 2852.10 | CSC32::P_BRADY | Wed May 07 1997 20:34 | 6 | ||
We are using the SSB CD. The CD is exactly as you described. I also
looked
into the DMQLOG.LOG, and the CLS version is 3.2.006.
| |||||