ProC programs crash on 11.23

[Sandman!]

The first two fields are exactly what you have supplied to the ps(1) command viz., vsz (the memory size of the process in 1K units) and pid (its process ID) and the last one is the process creation command line.

[dictum9]

The program crashed again today. The memory usage got as high as 18892 in 1K blocks. After restart, it's growing again.

Is there a kernel variable I can tune, or is this strictly a code issue?

The memory leak doesn't seem to be fixed.



18892 14395 /apps/qms/bin/qms1108a /bin/ON1108 /apps/qms/fims/upload /data/hnstest
1860 14016 /apps/qms/bin/qms1108wrc /bin/ON1108wrc /data/hnswrc
1256 925 sh /apps/qms/bin/qms1109_IRU.sh


Mon Jul 30 10:47:04 EDT 2007

18892 14395 /apps/qms/bin/qms1108a /bin/ON1108 /apps/qms/fims/upload /data/hnstest
1860 14016 /apps/qms/bin/qms1108wrc /bin/ON1108wrc /data/hnswrc
1256 925 sh /apps/qms/bin/qms1109_IRU.sh


Mon Jul 30 10:47:34 EDT 2007

1860 14016 /apps/qms/bin/qms1108wrc /bin/ON1108wrc /data/hnswrc
1256 925 sh /apps/qms/bin/qms1109_IRU.sh

[James R. Ferguson]

Hi:

> The program crashed again today. The memory usage got as high as 18892 in 1K blocks. After restart, it's growing again. Is there a kernel variable I can tune, or is this strictly a code issue? The memory leak doesn't seem to be fixed.

Why do you believe that you have a memory leak? Usually, you would see the memory utiliztion for the processs grow until your program fails calling 'malloc' with an error of ENOMEM. With such a failure, the call will also return a NULL pointer.

In all your posts, I don't see evidence of continued memory growth nor any 'errno'. As already noted by others, you need to capture and test for non-zero 'errno' after every system call.

For the heap (data) (governed by 'malloc'), the kernel parameter 'maxdsiz' and 'madsiz_64bit' are the fences for the maximum data size of 32-bit and of 64-bit processes respectively.

Regards!

...JRF...

[Sandman!]

What do you mean by the "program crashed"? Did it produce a core dump? You can get a core dump by sending the SIGABRT signal & see what's happening.

[Dennis Handly]

>The program crashed again today. ... or is this strictly a code issue?

If you think you have a memory leak, you can use wdb's leak detection commands.
(gdb) set heap-check on
run it
(gdb) info leaks

[dictum9]

The problem is resolved.
It was caused by a file being opened but not closed.

Thank you all for the invaluable contributions.

[A. Clay Stephenson]

I'm going to guess that you finally captured errno properly and it was either EMFILE or ENFILE and that is how you were able to wrestle this steer to the ground.