yyyark1
13th October 2003, 15:24
Hello,
I have a program that is ran in batch and occassionally a "core" file is created in the Unix directory when it is running. The core files is not created every time, it varies. I cannot determine why some times the "core" file is created. Since this file is so large it usually kills our job and we cannot run it again until we remove the "core" file. Does anyone have any idea why the core file gets created? Is there any way I can prevent this from continuing to happen?
Thanks,
yyyark1
zardoz
13th October 2003, 16:09
Core files are the dump of the memory area. It happens when something goes wrong in unix. There are legends :confused: that this kind of files can be used by some unix guru to give responses about the cause of the error, but I never encountered such a person, so I simply delete it from my space when it happens that I found in my system :D
Brendan Shine
14th October 2003, 03:22
If you are interested in looking at the core dump you can use "strings -a" which will show all readable characters in a file.
OmeLuuk
14th October 2003, 12:33
There are indeed ways to trace a core file. You need a debugger (which is rather OS specific). Then you need to restart your binary with specific options using the core as input...
Strings on a corefile may also help to determine the cause because at least you can tell what binary has crashed on you. Better is to view only the first part of the corefile, because further on there is binary information of the memory content, but that is way too specific info - handy for the debugger, not for laymen.
If you find that one of the portingset binaries cause the core file, log a case with Baan.
You can also prevent corefiles to be created or have them made in /dev/null, but that is never a solution... they should not be made at all.
tools123
15th October 2003, 04:44
I see core files whenever I do mport using exchange.So far no errors within the log of the exchange.
I delete them out.
Any service pack issues specific to this?
Atul Khungar
11th November 2003, 23:24
OmeLuuk
Is there a setting in unix where I can specify that I do not want core files to be created ???:confused:
Thanks
OmeLuuk
12th November 2003, 15:23
There is a setting CORE= in the bshell, but that does not prevent a core file to be made....
What you can do is:$ ln -s /dev/null core
$ ls -l core
lrwxr-xr-x 1 user1 bsp 9 Nov 11 11:11 core -> /dev/null
vahdani
12th November 2003, 23:08
Hi all,
it is my understanding that a core dump indicates an internal error in the Unix application, in our case the Baan porting set. Baan programs run on top of bshell as a kind of Virtual Machine and don't access Unix directly which means they can not cause a core dump due to any programing errors.
So by any core dumps either open a case by Baan or try installing a new porting set when available.
OmeLuuk
13th November 2003, 10:39
On the one hand side you are right,... but on the other hand... in the mean time between logging a case and having it solved, it is nice not to have the system get full with core files on all user home directories...
jpvdgiessen
17th November 2003, 19:53
I shouldn't (symbolic) link a core to /dev/null because if there is a real problem a core dump has valuable information.
I delete them once a day via the cron with the following command: find / -name core -exec rm -f {} \;
dave_23
17th November 2003, 20:36
I think if you set CORE=0 in your environment a core will not be created...
One other things, Usually, in Baan, if a core gets created, its becuase the bshell or driver ran out of memory.. check your ulimits (ulimit -a [this differs from OS to OS]) for that user, pay attention to these:
data(kbytes) 1000000
stack(kbytes) 51200
If you're getting cores try bumping these up some and see if that helps.
Dave
OmeLuuk
18th November 2003, 09:26
JP Core contains valuable information for those who can read it, all others have problems with the core files being created. When logging the case, you can save one core file (if they need it, mostly don't).
The CORE=0 setting did not prevent my bshell to coredump after kill -3 <PID>
man kill:
3 SIGQUIT Quit Terminate with core dump; can be trapped
dave_23
18th November 2003, 20:29
Can't find my info on that CORE variable. its either a shell specific thing or specific to some app i was having a problem with long ago.. ah well
Try
ulimit -c 0
Instead.
This differes based on the OS, but most of 'em will allow it.
Dave
OmeLuuk
19th November 2003, 10:44
I find:
AIX: man ulimit: -c Specifies the size of core dumps, in number of 512-byte blocks.
HP11: ulimit -c 0
ksh: ulimit: bad option(s)
How can the same be obtained on HPUx11? (other than symlink?)
dave_23
19th November 2003, 16:15
Not sure on HP-UX 11, i know if you do it as root it should work
# ulimit -c 0
# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 65536
memory(kbytes) unlimited
coredump(blocks) 0
nofiles(descriptors) 2048
# uname -a
HP-UX fnord B.10.20 A 9000/826 115330361 two-user license
But i haven't been able to figure out how to do it for user processes. they must make you use SAM or something.
Dave