First, you run that output through c++filt, which demangles the C++ symbols into human-readable, and source-code cross-reference-able output.
From that you see that the PROFILE constructor has called new[] which has caused an exception to be raised for which there is no handler (std::terminate is called), which causes the program to abort, generating a core dump.
You can wrap the call to new[] in a try...catch block to see what the exception is. I cannot remember off the top of my head what exceptions new[] can raise and under what circumstances, but one cause of new failures is a corrupt heap, commonly from either overwriting the bounds of an allocation or a double delete.
You can diagnose these memory errors using programs like valgrind (free) or purify (commercial, assuming it still exists - I last used it 15 years ago). valgrind would be a good start and it will show you your memory errors of the form mentioned above.
You can go deeper with the core dump using gdb to inspect the memory image of your program at the time it crashed, but no-one here can really help with that - you need to know the structure of your code and the expected memory layout to do much with this.
When a userland program crashes, it can leave a core file behind, containig a copy of the contents of the memory when it went down (the core name comes from the prehistory of computing, when memory was core). This is controlled by the ulimit(1) command, it is normally disabled as the core files are large and tend to confuse newbies. A core file can be analyzed by e.g. a debugger, together with the executable and symbol table, to find out what happened.
When the kernel crashes, it normally triggers a kernel panic. If the kernel has found some critical inconsistency, it really isn't wise to count on it bahaving sanely to write out anything. So no core gets generated, and the system goes down. Contents of registers and code surrounding the address where the problem happened is written to the console. It is a good idea to save this (e.g. take a picture) for possible later analysis.
A similar situation is the kernel Oops, when the kernel detects an inconsistency that isn't considered fatal. In that case (as in a kernel panic) contents of registers and code surrounding the address where the problem happened is written to the console, and also logged.
Best Answer
You need to execute
ulimit -c 0in the script that starts the webserver, probably/etc/init.d/apacheor/etc/init.d/httpd. Place it near the top, but don't make it the first line.Alternatively you can change the way the core dump is written, so that subsequent core dumps overwrite the previous instead of creating a new file. Add these lines to
/etc/sysctl.conf:and run
sysctl -p. Now the core dumps will be named simplycore.You could now also create a zero-sized file owned by root with no write permissions; as the core dump is written with the privileges of the process owner, it won't be able to overwrite that file, hence no core dump.