Highlighted
Absent Member.
Absent Member.
1611 views

Virtual Memory Problems

Jump to solution

Hello all,

We have problems with our vitual memory growing up when we close and open a subwindow in our program. I mean, when the window is closed, not all the virtual memory is unloaded, if the window is opened initially 100 kb are added to the virtual memory, but when is closed only 80 kb are unloaded. Test deactivating/activating copy resource option in the images are done, but the memory leak is still there. Actually, we don't manage the memory usage of our program, because acubench ( extend 8.0) do it itself and my question is if someone knows of any option (at runtime or design) that can be the answer to the problem.

Note: another subwindows in the program unload the memory correctly, and we are looking for the differences but... nothing at the moment.

Thanks for the tips!

0 Likes
2 Solutions

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Virtual Memory Problems

Jump to solution

Did the sub-window include a bit map, or other resource like a font? Have you monitored the memory usage using the debugger or using Windows .. as using the debugger should show the memory the runtime is actually using, ocassionally when looking at memeory usage with Windows, Windows doesn't release everything at a specific moment, it holds onto some so that it is available when the program needs it.

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Virtual Memory Problems

Jump to solution

Hi,

We get the problems (in fact some of them). It were some fonts loaded by the acubench that aren't destroyed when the windows is closed (fonts assigned in the screen editor), the same with the menu-handle of our windows, the LMRESIZE handle defined in lmresize.def (only having it in the .wrk section, it loads on memory and must be destroyed manually, no matter if you don't use it in "additional properties") and two images with the same name and handle (in fact they are the same image) but when assigned in the screen editor, we put different paths, and the automatic code were:

      Acu-Init-Bmp.

     * bitmap loading

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "C:\FondoAvisos.jpg" TO ACU-FULLBITMAPPATH

          NOT ON EXCEPTION

             INITIALIZE ACU-FULLBITMAPPATH

             INSPECT ACU-BITMAPPATH REPLACING TRAILING SPACE BY "\"

             INSPECT ACU-BITMAPPATH REPLACING TRAILING "\" BY LOW-VALUE

             STRING ACU-BITMAPPATH DELIMITED BY LOW-VALUE

                "\" DELIMITED BY SIZE

                "FondoAvisos.jpg" DELIMITED BY LOW-VALUE

             INTO ACU-FULLBITMAPPATH

          END-ACCEPT

          CALL "W$BITMAP" USING WBITMAP-LOAD ACU-FULLBITMAPPATH,

             GIVING FondoAvisos-jpg

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "panel4.bmp" TO ACU-FULLBITMAPPATH

      Acu-Init-Bmp.

     * bitmap loading

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "D:\FondoAvisos.jpg" TO ACU-FULLBITMAPPATH

          NOT ON EXCEPTION

             INITIALIZE ACU-FULLBITMAPPATH

             INSPECT ACU-BITMAPPATH REPLACING TRAILING SPACE BY "\"

             INSPECT ACU-BITMAPPATH REPLACING TRAILING "\" BY LOW-VALUE

             STRING ACU-BITMAPPATH DELIMITED BY LOW-VALUE

                "\" DELIMITED BY SIZE

                "FondoAvisos.jpg" DELIMITED BY LOW-VALUE

             INTO ACU-FULLBITMAPPATH

          END-ACCEPT

          CALL "W$BITMAP" USING WBITMAP-LOAD ACU-FULLBITMAPPATH,

             GIVING FondoAvisos-jpg

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "panel4.bmp" TO ACU-FULLBITMAPPATH

Acubench managed the load of this bitmaps thinking they were differents (it's normal, we put different paths but no warning showed) and "FondoAvisos-jpg" was loaded two times with the same handle.

Thanks shjerpe for the answer, we get the fonts problems with your tip.

View solution in original post

0 Likes
2 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Virtual Memory Problems

Jump to solution

Did the sub-window include a bit map, or other resource like a font? Have you monitored the memory usage using the debugger or using Windows .. as using the debugger should show the memory the runtime is actually using, ocassionally when looking at memeory usage with Windows, Windows doesn't release everything at a specific moment, it holds onto some so that it is available when the program needs it.

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Virtual Memory Problems

Jump to solution

Hi,

We get the problems (in fact some of them). It were some fonts loaded by the acubench that aren't destroyed when the windows is closed (fonts assigned in the screen editor), the same with the menu-handle of our windows, the LMRESIZE handle defined in lmresize.def (only having it in the .wrk section, it loads on memory and must be destroyed manually, no matter if you don't use it in "additional properties") and two images with the same name and handle (in fact they are the same image) but when assigned in the screen editor, we put different paths, and the automatic code were:

      Acu-Init-Bmp.

     * bitmap loading

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "C:\FondoAvisos.jpg" TO ACU-FULLBITMAPPATH

          NOT ON EXCEPTION

             INITIALIZE ACU-FULLBITMAPPATH

             INSPECT ACU-BITMAPPATH REPLACING TRAILING SPACE BY "\"

             INSPECT ACU-BITMAPPATH REPLACING TRAILING "\" BY LOW-VALUE

             STRING ACU-BITMAPPATH DELIMITED BY LOW-VALUE

                "\" DELIMITED BY SIZE

                "FondoAvisos.jpg" DELIMITED BY LOW-VALUE

             INTO ACU-FULLBITMAPPATH

          END-ACCEPT

          CALL "W$BITMAP" USING WBITMAP-LOAD ACU-FULLBITMAPPATH,

             GIVING FondoAvisos-jpg

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "panel4.bmp" TO ACU-FULLBITMAPPATH

      Acu-Init-Bmp.

     * bitmap loading

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "D:\FondoAvisos.jpg" TO ACU-FULLBITMAPPATH

          NOT ON EXCEPTION

             INITIALIZE ACU-FULLBITMAPPATH

             INSPECT ACU-BITMAPPATH REPLACING TRAILING SPACE BY "\"

             INSPECT ACU-BITMAPPATH REPLACING TRAILING "\" BY LOW-VALUE

             STRING ACU-BITMAPPATH DELIMITED BY LOW-VALUE

                "\" DELIMITED BY SIZE

                "FondoAvisos.jpg" DELIMITED BY LOW-VALUE

             INTO ACU-FULLBITMAPPATH

          END-ACCEPT

          CALL "W$BITMAP" USING WBITMAP-LOAD ACU-FULLBITMAPPATH,

             GIVING FondoAvisos-jpg

          ACCEPT ACU-BITMAPPATH FROM ENVIRONMENT "Bitmap-Path"

          ON EXCEPTION

             MOVE "panel4.bmp" TO ACU-FULLBITMAPPATH

Acubench managed the load of this bitmaps thinking they were differents (it's normal, we put different paths but no warning showed) and "FondoAvisos-jpg" was loaded two times with the same handle.

Thanks shjerpe for the answer, we get the fonts problems with your tip.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.