HD54578: SERVER PROCESS DOESN'T RELEASE MEMORY WHEN CLIENT CLOSED VI EWER

APAR status

• Closed as Permanent restriction.

Error description

• Server process doesn't release memory when
  client closed viewer
  .
  Scenario :
  1. Start 3Dcom
  2. In Remote file tree, open a .model into 3DLV
  with V5 Server
  3. Check memory usage of GW0SRVCX process
  (ex. 34.9MB)
  4. Open another model into 3DLV then check
  GW0SRVCX memory usage ( => 37.6MB)
  5. Repeat procedure-4 with another CATIA Model.
  6. After 11 models were opened , allocated
  memory for GW0SRVCX is 399MB.
  7. Close all Viewers screens on 3dcom.
  8. Check GW0SRVCX process memory.
  .
  Problem :
  GW0SRVCX process still using 399MB memory in
  server.
  .
  Expected result :
  When client closes each viewer, memory for
  GW0SRVCX process should be released.
  .
  

Local fix

Problem summary

• Server process doesn't release memory when client closed     vi
  ewer
  Server process doesn't release memory when
  client closed viewer
  .
  Scenario :
  1. Start 3Dcom
  2. In Remote file tree, open a .model into 3DLV
  with V5 Server
  3. Check memory usage of GW0SRVCX process
  (ex. 34.9MB)
  4. Open another model into 3DLV then check
  GW0SRVCX memory usage ( => 37.6MB)
  5. Repeat procedure-4 with another CATIA Model.
  6. After 11 models were opened , allocated
  memory for GW0SRVCX is 399MB.
  7. Close all Viewers screens on 3dcom.
  8. Check GW0SRVCX process memory.
  .
  Problem :
  GW0SRVCX process still using 399MB memory in
  server.
  .
  Expected result :
  When client closes each viewer, memory for
  GW0SRVCX process should be released.
  .
  

Problem conclusion

• THIS PROBLEM IS PERMANENT RESTRICTION IN
  ENOVIA
  .
  Abstract :
  Server process doesn't release memory when
  client closed viewer.
  .
  Explanations :
  In fact, this problem is not a DS bug.
  This problem is actually a permanent restriction as
  the OS is not showing a correct counter of the
  memory consumption. When the process is
  allocated memory, the increase in memory
  consumption is shown. But when the memory is
  freed, the corresponding decrease of memory
  consumption is not updated. Since there is not
  reduction in memory consumption usage, it
  appears to be a memory leak. We have checked in
  our code manually and ensured that there are no
  memory leaks.
  In fact, under unix , the memory server never
  decreases. Unix Operating system keeps the
  allocated memory for future task, even if the
  memory was released in the code. It is the
  standard behavior of OS.
  .
  To check that there is no memory leak, 3 scenario
  can be run :
  * Scenario A:
  - Open a big size model in 3DLV. Check the
  consumption of the memory for GW0SRVCX
  process. Lets say it is 200 MB.
  - Close the model in 3DLV.
  Expected Result :The consumption of the memory
  for GW0SRVCX process will remain 200MB.(No
  freed memory updated)
  - Open the same model again in 3DLV.
  Expected Result: The consumption of memory
  should increase marginally.(Say 205 MB due to
  fragmentation)
  * Scenario B:
  - Open a big size model in 3DLV. Check the
  consumption of the memory for GW0SRVCX
  process. Lets say it is 200 MB.
  - Close the model in 3DLV.
  Expected Result :The consumption of the memory
  for GW0SRVCX process will remain 200MB.(No
  freed memory updated)
  - Open a small model in 3DLV.
  Expected Result: The consumption of memory
  should remain 200 MB. No extra memory should be
  allocated for the small model opened.
  * Scenario C:
  - Open a small size model in 3DLV. Check the
  consumption of the memory for GW0SRVCX
  process. Lets say it is 100 MB.
  - Close the model in 3DLV.
  Expected Result: The consumption of the memory
  for GW0SRVCX process will remain 100MB.(No
  freed memory updated)
  - Open the big size model used in the above
  scenario.
  Expected Result: The memory consumption shown
  should not be more than 200 MB to 210 MB.
  .
  These scenario show that there is no bug in 3dcom.
  .
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels