Growing process memory

[Benedetto Mangiapane]

I've two system for a test.
In the first, the memory of a process growing (at least 400Mb and after the kernel kill it). In the second with the same process, the memory is normal (24 Mb).

(uname -a)
HP-UX first B.11.11 U 9000/800 1106414681 unlimited-user license

HP-UX second B.11.11 U 9000/800 3678999180 unlimited-user license

The process use the STL routine (map, list, ...), and TCSI Solution Core OSP framework.

Question:
1 - There are particular cargo conditions, that they produce results of this type?

2 - It is possible that the memory in a system comes freed automatically, and in the other not?

3 - How I can control and verify these anomalies?

Thanks.
Benedetto.

[Peter Godron]

Benedetto,
if you are running the same executable on two machines and the behaviour is different, you must have a different environment/libraries.

Have you tried re-compiling the code into a standalone module (no calls to external libs) and re-running it?

[Benedetto Mangiapane]

I cannot compile the process with the method stand-alone because part of a package larger that contains other processes that link the shared libraries.

I would want to try to understand what happens...

I have need of some suggestions in order to analyze the problem and to try to find the cause.

[Dennis Handly]

You should use gdb's leak detection commands to see where it is leaking/growing. You can download gdb for free.

[Benedetto Mangiapane]

Hi,
I have tried to find through wdb the memory leaks, but I have not found any. There is virtual memory busy. I use the STL very much, like map very, vector, list... etc.

I think that the problem comes from the the free or delete operation when it comes freed the memory used from the STL object.

(In the wdb memory use window, there are many new [] operations...)

I go for the just road?
Thanks.

[Dennis Handly]

>I have tried to find through wdb the memory leaks, but I have not found any.

If no leaks, can you compare the systems by using "info heap" on both.

There should be a big difference if one is 400 Mb and the other 24 Mb. Do both processes have the same inputs?

[Benedetto Mangiapane]

The same input for the processes.

In the thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1076848, Don Morris talk about similar problem.

Insert the swapinfo of two nodes:

FIRST > swapinfo -atm
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 2640 1456 64% 0 - 1 /dev/vg00/lvol2
dev 1600 0 1600 0% 0 - 2 /dev/vg00/lvol_swap
dev 8000 2635 5365 33% 0 - 1 /dev/vg_swap/lvol_swap2
reserve - 8205 -8205
memory 6286 4217 2069 67%
total 19982 17697 2285 89% - 0 -

SECOND > swapinfo -atm
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 2751 1345 67% 0 - 1 /dev/vg00/lvol2
dev 8192 2752 5440 34% 0 - 1 /dev/vg00/lvol_swap
reserve - 6785 -6785
memory 6282 5585 697 89%
total 18570 17873 697 96% - 0 -

[Dennis Handly]

>The same input for the processes.

Do you have the same patches on each?
And what does gdb's heap commands say about each?

>Don Morris talk about similar problem.

Yes, but there never was a resolution.

>Insert the swapinfo of two nodes:

This just shows more VM total on FIRST.

[Benedetto Mangiapane]

To the verification through the gdb (wdb), info heap it gives back to me "Heap analysis is not enabled now."

To enable?

[Benedetto Mangiapane]

Extract of info heap:

No. Total bytes Blocks Address Function
0 4055040 30 0x62867000 __alloc_stack()
1 2547160 28945 0x40f49700 __libc_mutex_alloc()
2 911168 1165 0x40ba2cf0 operator new(unsigned long)()
3 370494 1 0x407050f0 sktsfMalloc()
4 340105 12940 0x4112d5c8 operator new(unsigned long)()
5 281764 6 0x4076afa8 lxldalc()
6 262496 1 0x408094a0 nsgbliuc()
7 257294 9891 0x40f4f828 operator new(unsigned long)()
8 230296 2617 0x406891b0 __libc_mutex_alloc()
9 157144 4936 0x40b39ad8 operator new(unsigned long)()
10 145768 6 0x40f60b60 operator new(unsigned long)()
11 139264 1 0x4087d2c8 slwmmgetmem()
12 94080 84 0x41332130 operator new(unsigned long)()
13 69632 1 0x6297d000 __alloc_stack()
14 65620 1 0x407f9438 nsgbliuc()
15 65620 1 0x407e93d0 nsgbliuc()
16 65620 1 0x407d9368 nsgbliuc()
17 65620 1 0x407c9300 nsgbliuc()
18 65608 11 0x409349b0 operator new [](unsigned long)()
19 65536 1 0x40af6c10 operator new [](unsigned long)()
20 65288 9 0x4077f818 sktsfMalloc()
21 65000 1 0x40558520 operator new [](unsigned long)()
22 57344 1 0x40849610 nsgbliuc()
23 49468 9 0x40c1c128 operator new(unsigned long)()
24 30561 1165 0x412bf550 operator new(unsigned long)()
25 28160 55 0x4054e7d8 operator new [](unsigned long)()
26 24064 47 0x40933dd8 operator new [](unsigned long)()
27 20340 1 0x4075f840 lxldalc()
28 20000 1 0x40548d48 operator new [](unsigned long)()
29 18944 8 0x409c8e60 __nss_XbyY_buf_alloc()
30 17896 1 0x40765030 sktsfMalloc()
31 16844 5 0x40c271f0 operator new(unsigned long)()
32 16416 2 0x406fcef8 _findbuf()
33 16384 8 0x4097c300 memset()
34 16280 10 0x40e14a70 operator new(unsigned long)()
35 9320 1165 0x40962d80 operator new(unsigned long)()
36 9272 61 0x40782a90 operator new(unsigned long)()
37 9036 753 0x406e7018 operator new(unsigned long)()
38 8772 731 0x406db368 operator new(unsigned long)()
39 8704 17 0x40592f68 operator new [](unsigned long)()
40 8240 2 0x4076bb58 sktsfMalloc()
41 8060 31 0x405536a0 operator new(unsigned long)()
42 7728 1 0x408608b8 nsgbliuc()
43 7080 30 0x40575b30 __pthread_id_lookup()
44 6720 5 0x40942d38 operator new(unsigned long)()
45 6144 12 0x4054f458 operator new [](unsigned long)()
46 5760 30 0x406f7a50 __private_data_setup()
47 5632 1 0x4053c640 __libCsup_mutex_init()
48 4480 1 0x406fef18 localtime_r()
49 4448 1 0x4085b368 nsgbliuc()
50 4264 1 0x408741d8 slwmmgetmem()
51 4200 1 0x407bf8b0 nngsini_init_streams()
52 4187 295 0x40580470 operator new [](unsigned long)()
53 4136 1 0x4077c740 sktsfMalloc()
54 4096 2 0x408626f8 nlhtnsl()
55 4096 2 0x40862f08 nlhtnsl()
56 3920 35 0x4085dd30 operator new(unsigned long)()
57 3584 32 0x4085e530 operator new(unsigned long)()
58 3540 295 0x4057dea8 operator new(unsigned long)()
59 3468 1 0x40875290 lpmrist()
60 3360 35 0x406f4ac0 operator new(unsigned long)()
61 3300 55 0x40546928 operator new(unsigned long)()
62 3072 1 0x40c1b0b0 operator new(unsigned long)()
63 2664 14 0x40555bd0 operator new [](unsigned long)()
64 2536 159 0x406e8c08 operator new [](unsigned long)()
65 2440 2 0x40c23ed0 operator new(unsigned long)()
66 2368 1 0x408646c8 __nss_XbyY_buf_alloc()
67 2268 1 0x40865018 nsmal()
68 2208 1 0x4076b2a8 kouodalc()
69 2184 31 0x406d9058 operator new [](unsigned long)()
70 2160 90 0x40864328 operator new [](unsigned long)()
71 2136 1 0x407647c8 lxldalc()
72 2104 1 0x408ab6e0 __nss_XbyY_buf_alloc()
73 2070 1 0x408aa690 nsbGetBFS()
74 2070 1 0x408a8c08 nsbGetBFS()
75 2070 1 0x408aaeb8 nsbGetBFS()
76 2070 1 0x408a9e68 nsbGetBFS()
77 2070 1 0x408a9430 nsbGetBFS()
78 2068 11 0x409087a0 operator new(unsigned long)()
79 2048 1 0x40b08c60 operator new [](unsigned long)()
80 2048 1 0x40b09470 operator new [](unsigned long)()
81 2048 1 0x40b08450 operator new [](unsigned long)()
82 2048 1 0x40b07c40 operator new [](unsigned long)()
83 2048 1 0x40b07430 operator new [](unsigned long)()
84 2048 1 0x40ad09d0 operator new [](unsigned long)()

....