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

Conference bulova::decwindows

Title:DECWINDOWS
Notice:DECwindows Motif V1.2-4 SSB kits: note 5519
Moderator:GRIM::MESSENGER
Created:Wed Nov 28 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5861
Total number of notes:24081

5799.0. "DECW$SERVER_0 virtual memory increased ?" by DEKVC::TAEGYUSOHN () Tue Mar 11 1997 18:57

    Hello,
    
    I have a customer is running a windows application on a VAX4000-VLC
    with OpenVMS VAX V6.1 Motif V1.2-3.
    It seems to continuously grow in VA size. So Pagefile quota was
    insufficient. When raised the PGFLQUO from 100000 to 300000, then
    also DECW$SERVER_0 process consumed most of them.
    "Insufficient virtual address space" error was logged in the error log
    file for the process.
    I want to know if this problem is in the product or application
    program.
    
    Thanks in advance.
     
    
T.RTitleUserPersonal
Name
DateLines
5799.1GRIM::MESSENGERBob MessengerWed Mar 12 1997 10:5221
Re: .0

>    I have a customer is running a windows application on a VAX4000-VLC
>    with OpenVMS VAX V6.1 Motif V1.2-3.
>    It seems to continuously grow in VA size.

What seems to grow in VA size: the application process or the
DECW$SERVER_0 process?

>    So Pagefile quota was
>    insufficient. When raised the PGFLQUO from 100000 to 300000, then
>    also DECW$SERVER_0 process consumed most of them.

Was PGFLQUOTA increased for the server process or for the user's account?

>    "Insufficient virtual address space" error was logged in the error log
>    file for the process.

Which process: the application process or DECW$SERVER_0?

				-- Bob
5799.2DECW$SERVER_0 process.DEKVC::TAEGYUSOHNWed Mar 12 1997 23:0594
Thanks for your reply.
This problem was in the DECW$SERVER_0 process.
Please review the following error log.



=================================================================
26-FEB-1997 16:08:35.8 Hello, this is the X server
This is the DECwindows X11 display server for OpenVMS VAX V6.1-940212
		compiled on Feb 12 1994 at 19:04:03
Dixmain address=0001940c
Server is running in bug-compatible mode
Now attach all known txport images
DECW$TRANSPORT_COMMON image base address: 00001200
DECW$TRANSPORT_DECNET image base address: 007BEE00
%DECW-I-ATTACHED, transport DECNET attached to its network
DECW$TRANSPORT_LOCAL image base address: 007C7000
1 fonts in SYS$COMMON:[SYSFONT.DECW.CURSOR32]DECW$FONT_DIRECTORY_CURSOR32.DAT;1
3 fonts in SYS$COMMON:[SYSFONT.DECW.CURSOR16]DECW$FONT_DIRECTORY_CURSOR16.DAT;1
347 fonts in SYS$COMMON:[SYSFONT.DECW.100DPI]DECW$FONT_DIRECTORY_100DPI.DAT;1
352 fonts in SYS$COMMON:[SYSFONT.DECW.75DPI]DECW$FONT_DIRECTORY.DAT;6
44 fonts in SYS$COMMON:[SYSFONT.DECW.COMMON]DECW$FONT_DIRECTORY_COMMON.DAT;1
48 fonts in SYS$COMMON:[SYSFONT.DECW.100DPI]DECW$FONT_ALIAS_100DPI.DAT;1
14 fonts in SYS$COMMON:[SYSFONT.DECW.100DPI]DECW$FONT_ALIAS_100_I18N.DAT;2
11 fonts in SYS$COMMON:[SYSFONT.DECW.100DPI]DECW$FONT_ALIAS_100_KO_KR.DAT;2
46 fonts in SYS$COMMON:[SYSFONT.DECW.100DPI]DECW$FONT_ALIAS_GS_100DPI.DAT;1
71 fonts in SYS$COMMON:[SYSFONT.DECW.75DPI]DECW$FONT_ALIAS.DAT;2
10 fonts in SYS$COMMON:[SYSFONT.DECW.75DPI]DECW$FONT_ALIAS_100_ASIAN.DAT;1
11 fonts in SYS$COMMON:[SYSFONT.DECW.75DPI]DECW$FONT_ALIAS_100_KO_KR.DAT;1
9 fonts in SYS$COMMON:[SYSFONT.DECW.75DPI]DECW$FONT_ALIAS_75_I18N.DAT;2
2 fonts in SYS$COMMON:[SYSFONT.DECW.75DPI]DECW$FONT_ALIAS_75_KO_KR.DAT;3
37 fonts in SYS$COMMON:[SYSFONT.DECW.COMMON]DECW$FONT_ALIAS_COMMON.DAT;1
%LCG-I-SUPPORT_LOADED, LCG support loaded, compiled: Feb 12 1994 18:53:24
%LCG-I-INIT_ADDRESS, lcg_InitOutput address=007D99EC (hex)
%LCG-I-CLIP_LIST_POOL_SIZE, clip list pool size = 00010000 (hex)
Connection Prefix: len == 61
26-FEB-1997 16:09:00.6 Now I call scheduler/dispatcher
26-FEB-1997 16:09:32.7 %LIB-E-ACTIMAGE, error activating image VSHJJ4$DKA300:[SYS0.SYSCOMMON.][SYSLIB]DECW$SVEXT_SHAPE.EXE;
26-FEB-1997 16:09:32.7 -RMS-E-FNF, file not found
26-FEB-1997 16:09:32.9 -ECWP-W-NORMAL, normal successful completion
26-FEB-1997 16:09:33.0 %LIB-E-ACTIMAGE, error activating image VSHJJ4$DKA300:[SYS0.SYSCOMMON.][SYSLIB]DECW$SERVER_EXTENSION_SHAPE.EXE;
26-FEB-1997 16:09:33.1 -RMS-E-FNF, file not found
26-FEB-1997 16:09:33.2 -ECWP-W-NORMAL, normal successful completion
Server internal runtime error threshold exceeded(code = 158217)
, server performance may be degraded.
%LCG-I-CONDITION_HANDLER_CALLED, the LCG condition handler has been called
%LCG-I-CONTINUE_REQUESTED, DDX requests server continue despite exception
Insufficient virtual memory <==============

Unrecoverable server internal error(error code = 1409559) found, terminating all connections.
Mapped Images...
 
  START       END        LENGTH    IMAGE NAME
  -----       ---        ------    ----------
     200        7ff        5ff    DECW$SERVER_MAIN
    5c00      66dff      611ff    DECW$SERVER_DIX
   b1c00      c9bff      17fff    VAXCRTL
   b1400      b1bff        7ff    CMA$TIS_SHR
   66e00      911ff      2a3ff    MTHRTL
   91200      b13ff      201ff    LIBRTL
    1200       5bff       49ff    DECW$TRANSPORT_COMMON
     800       11ff        9ff    DECW$SECURITY
  7bee00     7c4fff       61ff    DECW$TRANSPORT_DECNET
  7c5000     7c5dff        dff    DECW$TRANSPORTMSG
  7c5e00     7c6fff       11ff    VAXCMSG
  7c7000     7c8fff       1fff    DECW$TRANSPORT_LOCAL
  7d9000     7f61ff      1d1ff    DECW$SERVER_DDX_GF

Exception Call stack dump follows: 
 
     PC     IMAGE+offset of call 
     --     -------------------- 
   c050d     VAXCRTL + e90d 
   109a8     DECW$SERVER_DIX + ada8 
    fa0f     DECW$SERVER_DIX + 9e0f 
  7dbe12     DECW$SERVER_DDX_GF + 2e12 
   2510a     DECW$SERVER_DIX + 1f50a 
   21d17     DECW$SERVER_DIX + 1c117 
    f166     DECW$SERVER_DIX + 9566 
   12355     DECW$SERVER_DIX + c755 
   11e15     DECW$SERVER_DIX + c215 
   19785     DECW$SERVER_DIX + 13b85 
 
********** marking the end of call stack dump **********
********************************************************
** SERVER INTERNAL RUN TIME ERROR EXCEEDED, SERVER HAS JUST CRASHED!! **
************************************************************************
 2-MAR-1997 12:30:40.1 FreeDefaultPixmaps - default stipple still being referenced.
 2-MAR-1997 12:30:40.4 FreeAllUnusedFonts: gc_ref_count = 1 for FIXED_100DPI.DECW$FONT
 2-MAR-1997 12:30:40.5 %LCG-E-DMDS_NOT_DELETED, DMD's not properly deleted before screen close
 2-MAR-1997 12:30:43.0 %LCG-I-AST_CANCELLED, AST called with status = CANCEL
 2-MAR-1997 12:30:43.2 
Fatal server bug!
 2-MAR-1997 12:30:43.2 Server runtime error limit exceeded - type @SYS$MANAGER:DECW$STARTUP server to restart, or see your system manager. 2-MAR-1997 12:30:43.2 
5799.3GRIM::MESSENGERBob MessengerThu Mar 13 1997 11:1132
Thanks for clarifying that it's the server process and not the application
process that is consuming apparently unlimited amounts of virtual memory.
I would still suspect a problem in the application, though, because it
might be making X requests that consume resources in the server without
making the X requests to free those resources.  It could also be a problem
in the Motif toolkit or in the server itself.

If you have access to the application's source code I think the first
thing to do is simply to look at the code and verify that everything that
the user creates in the server (e.g. windows, pixmaps, colormaps,
properties, selections etc.) is freed when it is no longer needed.  A
common error would be to create an object such as a pixmap in every
iteration through a loop without freeing and/or reusing the object.

If this visual inspection doesn't uncover the problem you could try
to narrow it down to find which subroutine in the application, and
ultimately which X server request, is triggering the memory leak.  This
might require modifying the application code, e.g. to temporarily comment
out routines that aren't being tested, or to call a particular subroutine
1000 times instead of 10 times and seeing whether this makes the problem
worse.

Another approach would be to use a tool which intercepts and displays all
server requests and events, to see whether server resources are being
allocated and not freed.  This tends to generate a massive amount of
output, though, so this suggestion is more of a last resort.

Of course you can always elevate this as an IPMT case, but I think you
should first try to demonstrate that the memory leak isn't a problem with
the customer's application.

				-- Bob
5799.4more Info.DEKVC::JUNMOKSONGTue Mar 18 1997 21:3034
     
    
     Hi,
     
     Thank you for your support.
     I worked with TG shon and we had following log:
    
     What do you think of following log?
     From this, can we decide what problem it is?
     
[0;0HProcess Name: DECW$SERVER_0  State: HIB  Actual time: 17-MAR-1997 14:28:39.24
Image Name: DECW$SERVER_MAIN   PID: 111 Mode: OTHER Node: VSHJJ1       
CpuTime :  60802.96 seconds   Subprocess Limit/Count :    8/ 0
Process Quota Information:
              Quota    Used    (pct.)  MAX_Used since  3-MAR-1997 17:29:27.43
ASTLM           100       6       6%       7
FILLM           200      26      13%      26
DIOLM           100       0       0%       1
BIOLM           100       6       6%       7
BYTLM         37456     192       0%     192
ENQLM           512      13       2%      13
TQLM              8       0       0%       0
PGFLQUOTA    300000  299466      99%  299466 1000000  VIRTUALPAGECNT  
VIRTPEAK     300000  303629     101%  303629 1000000  VIRTUALPAGECNT  
GBLPAGES     100000   31574      31%   31574
GBLSECTIONS    1000     349      34%     349
Working Set Info:     Max Size 
WSEXTENT     22504                            22500  PQL_DWSEXTENT
WSQUOTA       2564                              614  PQL_DWSQUOTA 
WSDEFAULT     1028                              388  PQL_DWSDEFAUL
WSSIZE       22500   22500                    22500  WSMAX        
PAGES        22500                         59287606  FAULTS       


5799.5GRIM::MESSENGERBob MessengerWed Mar 19 1997 16:077
All the log file shows is that the server has used up all the available
virtual memory.  It doesn't show why this happened.

If you aren't able to analyze the customer's application then I guess
you'll have to elevate this as an IPMT case.

				-- Bob