CORE in PERL process?!?

[Enrico Venturi]

Hello colleagues,
we run a PERL process, which sometimes calls executable libraries; at a certain moment the process dumps because of a SIGSEGV .... it produces a core file ....
A PERL program can really produce a core?!?
How can I get informations from the core? i.e. where the memory fault occurred.....

Thanks a lot

Enrico

[Steve Steel]

Hi

Memory Usage - â What is using all of the memoryâ ?

by:eric.herberholz@hp.com

Last modified: August 19, 2004

Latest version available at external ftp site:

ftp://eh:spear9@hprc.external.hp.com/memory.htm


Look at J


Steve

[Muthukumar_5]

SIGSEGV ( signal for segmentation violation ) occurs because of memory access on voildated region and getting signal on that.

You can start to debug core file as,

file core
what core

I hope you knew some informations there on core file. core file is created because of getting signals for the memory problem.

It is good to start with debuggine mode to know the problem more.

[Enrico Venturi]

unfortunately the problem rarely occurs during the normal process behaviour, then we've to run it more and more times ...
very difficult to run in debug mode...

[Enrico Venturi]

for instance, through "xdb" is possible to understand where the fault occur in an executable.....
is there a similar tool for PERL modules?
by file and what I can get very few informations on the core, or better, on what caused the core (the SIGSEGV)

[ranganath ramachandra]

as suggested before, use the command 'file core' or 'what core' to see which program dumped the core - it should probably be from perl.

then use a debugger such as gdb to get a stack trace (perl path here is an example):
gdb /opt/perl/bin/perl core

gdb's backtrace (bt) command gives you the stack trace. you can also list the shared libraries loaded using "info sharedlibrary". if the backtrace is unable to list names of functions, you can check the instruction address and try finding out which shared library it was in, using the output of "info sharedlibrary".

[H.Merijn Brand (procura]

Since perl loads the modules/libs dynamically, there is nothing that holds you from using dbx or gdb on the running perl process.

A running perl script is nothing more than the perl process that runs the compiled script.

Problems arise when perl forks of other processes that crash, like when using DBI and backend SQL processes are started

Enjoy, Have FUN! H.Merijn