Core file for oracle concurrent manager

Last updated on August 25th, 2016 at 04:01 am

Oracle concurrent managers consists of many executable and we often faced various issues with it.When an executable ends with a segmentation fault or signal 11, a core file for oracle concurrent manager  should be created.

If you are not finding that a core file is created, then the ulimit may be set to 0 for core files on your system.
Check this as follows:
ulimit -a
ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) unlimited
coredump(blocks) unlimited
nofiles(descriptors) 4096
vmemory(kbytes) unlimited

Check the output for “core file size (blocks)” If this is set to 0 or a low value, it can be reset to allow core files of any size to be created in the current session using the syntax:
ulimit -c unlimited

If unix user has this set in the environment before starting the concurrent manager, and the Apps listener,
then the concurrent processing environment will be able to create core files.

The executable that is ending in segmentation fault or signal 11 should be relinked with debug symbols in
order to get a useful core file. This is done by passing the link_debug=y parameter to
For example: force=y link_debug=y “fnd FNDLIBR”

Once the executable is relinked with debug symbols and you have a core file, make sure you have the right
core file for the executable that crashed using the syntax:
file core
core: ELF 32-bit MSB core file SPARC Version 1, from ‘FNDLIBR’

Now use the debugger to get a stack trace.
For Linux the debugger is gdb:
gdb $FND_TOP/bin/FNDLIBR core
For Solaris the debugger is dbx:
dbx $FND_TOP/bin/FNDLIBR core

Leave a Reply