Hi All,

is there any way to find out the optimal/would be size of the cor dump file generated by the system while a process got terminated abnormally?

Basically we have been asked to provide the size of the core dump file being generated by the administrators who maintained the UNIX boxes. Currently it is 1GB but it easily exceed this allocated space. So we are looking for bigger suitable size.

Please helo advice.

Thanks,
Pushp.

Hi All,

is there any way to find out the optimal/would be size of the core dump file generated by the system while a process got terminated abnormally?

Basically we have been asked to provide the size of the core dump file being generated by the administrators who maintained the UNIX boxes. Currently it is 1GB but it easily exceeds this allocated space. So we are looking for bigger suitable size.

Please help advice.

Thanks,
Pushp.

How about ensuring that a "limit" won't be gone over?

bash and ksh have a builtin "ulimit" ksh, for example allows you to specify the max possible core size on a per process basis.

The size command gives the amount of space the image file (executable) will use
when it is run. If there is a lot of dynamic memory allocation it will not show up.
try: man size

Plus, production code should NOT be dumping core. That is an awful idea. If the code is dumping because of SIGBUS or SIGSEGV, you need to fix it, not allocate more core space. If some admin is terminating the process and forcing core dumps, you might want to look at adopting different procedures.

Thanks Jim.

but i was looking if there is any way we can find out the maximum possible size of generated core file so that we can allocate a 3-4 GB space for core file.

any pointers would be appreciated.

Thanks,
Pushp

Try instrumenting your code during a couple of test runs:
You can call getrusage() at the end of a run to see the amount of stack and heap memory your program has used. Then you can add the size of the "text" data segment (output of size command).

This sum will be very close to the max core size.

If you are worried only about certain signals causing core, then trap those signals, and in the signal trap call getrusage(). Again we are instrumenting the code.

Remove the instrumentation for production code once you have a handle on the situation.