Getting the core file under Linux Environment

Once again after long time, my techBlog is getting something...

When i started working on QNX environment, host environment was Linux. After few days of time, thought to do some experiements on target to know any different behavior of QNX, compare to Linux/Unix. Hence wrote small application programs. But got a question, How to compile for target..?Host machines Linux was installed with toolChain and got to know about 'qcc' command which is nothing but gcc for qnx. When i compiled using qcc command, executable getting created but it was not executing on target. When i looked at the file info,

a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

But the file info of the files which were getting executed on target were

a.out: ELF 32-bit LSB executable, Hitachi SH, version 1 (SYSV), dynamically linked (uses hared libs), not stripped

This is specific to Target, SH based MC. Then i understood that qcc was creating binaries for generic target (default x86), not for specific target. Then looked into makefiles which were with full of MACROS, no direct commands. When i saw the output of makefiles, i got that some configuration files is being used to cross compile which is a argument for qcc.

qcc -V3.3.5,gcc_ntoshle q.c

Above command could create a.out file for our target and i could execute and the file on actual target. After this, i could test something on target. After this i have tested some system calls related programs and etc. I was happy when i have done what i wanted... !!!!

Core file creation under Linux environment:

For segmentation fault kind of issues, .core file was getting created on target with the process name. If process/exe file name is test, test.core file was getting created on target which we use to debug the issue. From that core file, we could backtrace (execution stack) to understand the last line of code executed, using target version of gdb.

But i knew that QNX behavior is almost same as Linux/Unix because of POSIX compliance. Means, i was expected the same kind of core file creation on linux paltform also which was not happening. After discussion with my lecturer and googling, i came to know about 'ulimit'.

[pramoda@server ~]$ ulimit -a

core file size (blocks, -c) unlimited

data seg size (kbytes, -d) unlimited

file size (blocks, -f) unlimited

pending signals (-i) 1024

max locked memory (kbytes, -l) 32

max memory size (kbytes, -m) unlimited

open files (-n) 1024

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

stack size (kbytes, -s) 10240

cpu time (seconds, -t) unlimited

max user processes (-u) 8190

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

When i change ulimit value from 0 to unlimited, (ulimit -c unlimited) then for segFault erros, i could get core files in linux also. The filename will be like 'core.[PID]'. If the application file executed and if the PID of the same is 102302, then the core file will be core.102302.

To create the debug file, which is nothing buf object file, execute cc test.c -o test-debug command.

Using gdb, we can look into backtrace to get the execution stack.

[pramod@testServer ~]$ gdb test-debug core.14611

GNU gdb Red Hat Linux (6.1post-1.20040607.62rh)

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib64/tls/libthread_db.so.1".

warning: core file may not match specified executable file.
 

Core was generated by `./a.out'.

Program terminated with signal 6, Aborted.

Reading symbols from /lib64/tls/libc.so.6...(no debugging symbols found)...done.

Loaded symbols for /lib64/tls/libc.so.6

Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.

Loaded symbols for /lib64/ld-linux-x86-64.so.2

#0 0x00000031c992e4dd in raise () from /lib64/tls/libc.so.6

(gdb) bt

#0 0x00000031c992e4dd in raise () from /lib64/tls/libc.so.6

#1 0x00000031c992fc8e in abort () from /lib64/tls/libc.so.6

#2 0x00000031c9962b41 in __libc_message () from /lib64/tls/libc.so.6

#3 0x00000031c996846f in _int_free () from /lib64/tls/libc.so.6

#4 0x00000031c9968a06 in free () from /lib64/tls/libc.so.6

#5 0x000000000040057a in main ()

Most of the time, we get libc is the triggerer because of printf, sprintf kind of library calls. We may get more info like line number of our source file, function names etc which is depending on the workspace.

I am trying to get more info about ulimit and core files. Let me see...

http://www.qnx.com/developers/docs/6.3.2/neutrino/utilities/q/qcc.html?lang=jp