coredump

I am setting ulimit -c unlimited. And in c++ program we are doing struct rlimit corelimit; if (getrlimit(RLIMIT_CORE, &corelimit) != 0) { return -1; } corelimit.rlim_cur = RLIM_INFINITY; corelimit.rlim_max = RLIM_INFINITY; if (setrlimit(RLIMIT_CORE, &corelimit) != 0) { return -1; } but whenever program is getting crashed the core dump generated by it is getting truncated. BFD: Warning: /mnt/coredump/core.6685.1325912972 is truncated: expected core file size >= 1136525312, found: 638976. What can be the issue ? We are using Ubuntu 10.04.3 LTS Linux ip-<ip> 2.6.32-318-ec2 #38-Ubuntu SMP Thu Sep

The version of GDB that is available on HPUX has a command called "packcore", which creates a tarball containing the core dump, the executable and all libraries. I've found this extremely useful when trying to debug core dumps on a different machine. Is there a similar command in the standard version of GDB that I might find on a Linux machine? I'm looking for an easy command that someone that isn't necessarily a developer can run when things go bad on a production machine. The core file includes the command from which it was generated. Ideally this will include the full path to the

I am writing a python script to automate debugging core dump from gdb. i am trying to print data structure which includes kernel data structures and lists(e.g. struct list_head). For example the structure is something like this: struct my_struct { struct my_hardware_context ahw; struct net_device *netdev; struct pci_dev *pdev; struct list_head mac_list; .... .... }; i am using following API tp print this structure: gdb.execute('p (*(struct my_struct *)dev_base->priv)') so i am able to print the content of 'struct my_struct' , struct my_hardware_context ahw, but not the content of pointers and

Short of digging through GDB source, where can I find documentation about the format used to create core files? The ELF specification leaves the core file format open, so I guess this should be part of the GDB specifications! Sadly, I did not find any help in this regard from GNU's gdb documentation. Here's what I am trying to do: Map virtual addresses to function names in executable/libraries that comprised the running process. To do that, I would first like to figure out, from the core file, the map from virtual address space to the name of the executable file/libraries, and then dig into

Can Checkpoint/restart be implemented using the core dump of a process? The core file contains a complete memory dump of the process, thus in theory it should be possible to restore the process to the same state it was in when the core was dumped. No, this is not possible in general without special support from the kernel. The kernel maintains a LOT of per-process state, such as the file descriptor table, IPC objects, etc. If you were willing to make lots of simplifying assumptions, such as no open files, no open sockets, no living IPC objects, no shared memory regions, and more, then in

My program is statically compiled with dietlibc. It is compiled on ubuntu x64 (compiled for x86 using the -m32 flag) and is run on a centos x86. The compiled size is only about 100KB. I compile it with -ggdb3 and no optimization flags. My program uses signal.h to handle a SIGSEGV signal and then calls abort(). The program runs without problems for days but sometimes segfaults. This is when I get weird backtraces that I do not understand: username@ubuntu:~/Desktop$ gdb -c core.28569 program-name GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version