hutuamo / google-coredumper Goto Github PK

What steps will reproduce the problem?
1. Login into machine
2. Check out source code from repository
3. ./configure
4. make

What is the expected output? What do you see instead?
Make/Compilation is error instead of success. This is compilation error log: 

src/elfcore.c: In function 'CreatePipeline':
src/elfcore.c:1424:26: error: 'CLONE_VM' undeclared (first use in this function)
src/elfcore.c:1424:26: note: each undeclared identifier is reported only once 
for each function it appears in
make: *** [elfcore.lo] Error 1


What version of the product are you using? On what operating system?
+ My OS: Linux ubuntu 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 
17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.

+ readelf -n core-test
readelf: Error: Unable to read in 0x78 bytes of dynamic section
readelf: Error: Unable to read in 0x18 bytes of notes
Notes at offset 0x00000374 with length 0x0000107c:
  CORE      0x0000007c  NT_PRPSINFO (prpsinfo structure)
  CORE      0x00000124  NT_TASKSTRUCT (task structure)

Attached is the build.log that will give details of build for fedora rpm.

May you check this ? In case you require some more input, please ping :-)

--
Rakesh Pandit
Fedora Maintainer

What steps will reproduce the problem?
1. install ubuntu 10.04 
2. generate a core dump either with gcore or google-coredumper
3. try to load core dump in GDB.

What is the expected output? What do you see instead?
should actually have a usable core dump. instead you get a pile of shit.

i'm attaching a patch which adds a "--with-relrobug" flag to configure, which 
enables a define, which slightly tweaks the elfcore.c code to output segments 
which are marked as read-only, because one particular page in one of these read 
only segments is actually dirty.

let me know how i can help get this (or an equivalent) fix included.

Hi,

We developed in Amadeus a small extension to Google Coredumper to allow to very 
basically mimic gdb's breakpoint on process running in production environment.

The idea is to put a corepoint at time T at a given assembly instruction 
address. Then at a time T + 1, when one thread of the process meets this 
corepoint then a core dump file is generated, with the exact stack frame the 
thread had when it met the corepoint. Corepoints are one-time use only, so you 
can sefely use them in loops.

This is done without performance penalty, except at time T when you put the 
corepoint, and at time T + 1 when you remove the corepoint and you generate the 
core file: we need to completely stop all the threads via ptrace calls.

The implementation is quite basic (x64 only): like gdb, a corepoint is nothing 
more than replacing the original instruction by an interruption 3. This in 
terms generate a SIGTRAP signal handled in the faulty thread (if this signal is 
not masked). Coredumper registers a SIGTRAP signal handler which:
 - stops all threads with ptrace
 - replaces the int3 instruction by the original one
 - moves the saved $rip register to go back one instruction earlier (sizeof(int3) = 1)
 - generates a FRAME struct from the signal handler saved registers
 - generates a core dump file
 - resumes all threads

I guess the same could also be done in x86 or ARM.

The whole git patch is attached. Note that it requires that you generate all 
autotools files with autoreconf --install to build properly.

Cheers,
Romain

$ uname -a
FreeBSD locklhost.ll 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 
UTC 2009     [email protected]:/usr/obj/usr/src/sys/GENERIC  i386
$ make
if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I./src  -I./src  -fno-omit-frame-pointer -g -O2 -MT thread_lister.lo -MD -MP 
-MF ".deps/thread_lister.Tpo" -c -o thread_lister.lo `test -f 
'src/thread_lister.c' || echo './'`src/thread_lister.c; \
then mv -f ".deps/thread_lister.Tpo" ".deps/thread_lister.Plo"; else rm -f 
".deps/thread_lister.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -fno-omit-frame-pointer -g -O2 -MT thread_lister.lo -MD -MP -MF .deps/thread_lister.Tpo -c src/thread_lister.c  -fPIC -DPIC -o .libs/thread_lister.o
src/thread_lister.c:35:23: error: sys/prctl.h: No such file or directory
src/thread_lister.c: In function 'ListAllProcessThreads':
src/thread_lister.c:53: error: 'PR_GET_DUMPABLE' undeclared (first use in this 
function)
src/thread_lister.c:53: error: (Each undeclared identifier is reported only once
src/thread_lister.c:53: error: for each function it appears in.)
src/thread_lister.c:55: error: 'PR_SET_DUMPABLE' undeclared (first use in this 
function)

What steps will reproduce the problem?
1. run the unit test under 2.6.35 or later

What is the expected output? What do you see instead?
Failure to create a core file.

What version of the product are you using? On what operating system?
google-coredumper-r31 on ubuntu 2.6.35

Please provide any additional information below.

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace

adding :
sys_prctl(PR_SET_PTRACER, clone_pid); 
to ListAllProcessThreads after the clone seems to work ( but there is a better 
way to deal with it, I'm sure )

What steps will reproduce the problem?
1. Look at project home page
2. Notice platform support

What is the expected output? What do you see instead?
I expect to see the tested platforms up front, possibly with "expected" or "it 
might work" platforms as well. This would be Linux according to what I can dig 
out of the README and extrapolate that only Linux is supported (even though it 
only states Linux is tested).
I see no indication.

There are slight discrepancies between the contents of the tarball and the
contents of the svn repository.

The release process should be amended such that the tarballs exactly
reflect the repository state.

See also issue 3.

diff -rux.svn google-coredumper/Makefile.am coredumper-1.2.1/Makefile.am
--- google-coredumper/Makefile.am   2008-10-01 15:05:28.000000000 +0100
+++ coredumper-1.2.1/Makefile.am    2008-04-02 00:37:59.000000000 +0100
@@ -1,5 +1,8 @@
 ## Process this file with automake to produce Makefile.in

+# Make sure that when we re-make ./configure, we get the macros we need
+ACLOCAL_AMFLAGS = -I `pwd`/../autoconf
+
 # This is so we can #include <google/foo>
 AM_CPPFLAGS = -I$(top_srcdir)/src

diff -rux.svn google-coredumper/Makefile.in coredumper-1.2.1/Makefile.in
--- google-coredumper/Makefile.in   2008-10-01 15:05:28.000000000 +0100
+++ coredumper-1.2.1/Makefile.in    2008-04-04 16:24:29.000000000 +0100
@@ -227,6 +227,9 @@
 sysconfdir = @sysconfdir@
 target_alias = @target_alias@

+# Make sure that when we re-make ./configure, we get the macros we need
+ACLOCAL_AMFLAGS = -I `pwd`/../autoconf
+
 # This is so we can #include <google/foo>
 AM_CPPFLAGS = -I$(top_srcdir)/src
 googleincludedir = $(includedir)/google
Only in google-coredumper/: svn-commit.tmp

Check this:

https://bugzilla.redhat.com/show_bug.cgi?id=496523

And corresponding patch:
https://bugzilla.redhat.com/attachment.cgi?id=340306

--
Rakesh Pandit
Fedora Package Maintainer

Dear developers,

This is not a issue. The code skips device memory in following code? I checked 
if delete "|| is_device", the /dev/ memory can be dumped. But what does the 
comment "be careful not to touch mapped devices" point to? Any side effect?

src/elfcore.c:
           * Also, be careful not to touch mapped devices.
           */
          if ((mappings[i].flags & PF_R) == 0 || 
              mappings[i].start_address == mappings[i].end_address ||
              is_device) {
            num_mappings--;
          } else {
            i++; 
          }    

Your comment will be appreciated.

Xianlong

What steps will reproduce the problem?
1. Build the coredump library for 32 bit system
./configure "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
make
make install

2. call  WriteCoreDump("core.test") in signal handler
int main(void)
{
    struct sigaction sa;
    sigfillset(&sa.sa_mask);
    sa.sa_flags = SA_SIGINFO;
    sa.sa_sigaction = coredump_signal_handler;

    if( sigaction( SIGABRT, &sa, NULL ) == -1 )
    {
       fprintf(stderr, "core dump signal handler failed %s.\n", strerror(errno));
    }
}

void coredump_signal_handler(int signum, siginfo_t *info, void *data)
{
        const char *core_test = "core.test";

        WriteCoreDump(core_test);
        /* Keep going, we generated a core file,
        ** but we didn't crash.
        **/
}

3. program the code to call abort() in some other function.

4. Run the process.

Expected Output: core.test should be generated and the process should continue 
after dumping core.

Observed output: 2 core files are generated: core.test and 
core.tScriptTerm.5031.6. And the system crashes after dumping the core files.


What version of the product are you using? On what operating system?
I am using 1.2.1 version of core dumper library on linux Centos OS 6.6.

Please provide any additional information below.
To fix the run time issue with the library, I modified the fpxregs structure in 
./src/elfcore.c line # 87 as follows

#if defined(__i386__) || defined(__x86_64__)
  #if !defined(__x86_64__)
    typedef struct fpregs {     /* FPU registers                             */
      uint32_t  cwd;
      uint32_t  swd;
      uint32_t  twd;
      uint32_t  fip;
      uint32_t  fcs;
      uint32_t  foo;
      uint32_t  fos;
      uint32_t  st_space[20];   /* 8*10 bytes for each FP-reg = 80 bytes     */
    } fpregs;
    typedef struct fpxregs {    /* SSE registers                             */
    #define FPREGS fpxregs
  #else
    typedef struct fpxregs {    /* x86-64 stores FPU registers in SSE struct */
    } fpxregs;
    typedef struct fpregs {     /* FPU registers                             */
    #define FPREGS fpregs
  #endif
#ifdef KM15062015
    uint16_t  cwd;
    uint16_t  swd;
    uint16_t  twd;
    uint16_t  fop;
    uint32_t  fip;
    uint32_t  fcs;
    uint32_t  foo;
    uint32_t  fos;
    uint32_t  mxcsr;
    uint32_t  mxcsr_mask;
    uint32_t  st_space[32];     /*  8*16 bytes for each FP-reg  = 128 bytes  */
    uint32_t  xmm_space[64];    /* 16*16 bytes for each XMM-reg = 128 bytes  */
    uint32_t  padding[24];
#endif
  } FPREGS;
  #undef FPREGS
  #define regs i386_regs        /* General purpose regi

Please let me know if you need any other information.

Thanks
Kshitij

There are no tags in the svn repository. There should be tags exactly
recording what went into any particular versioned release.

Compile with ./configure --prefix=/users/dsdeldev/Coredumper/comp CC=icc
CFLAGS="-D__64BIT__ -D__LINUX64__ -D_LP64 -g -fPIC -w1 -O3 -pipe -Wall
-Wpointer-arith -Wshadow -Wmissing-prototypes -Wstrict-prototypes" CXX=icpc
CXXFLAGS="-D__64BIT__ -D__LINUX64__ -D_LP64 -g -fPIC -w1 -O3 -pipe -Wall
-Wpointer-arith -Wshadow -Wmissing-prototypes -Wstrict-prototypes"

execute gmake 

There are many error related to undefined identifiers:

/bin/sh ./libtool --tag=CC --mode=link icc -fno-omit-frame-pointer
-D__64BIT__ -D__LINUX64__ -D_LP64 -g -fPIC -w1 -O3 -pipe -Wall
-Wpointer-arith -Wshadow -Wmissing-prototypes -Wstrict-prototypes   -o
coredumper_unittest  coredumper_unittest.o libcoredumper.la -lpthread 
icc -fno-omit-frame-pointer -D__64BIT__ -D__LINUX64__ -D_LP64 -g -fPIC -w1
-O3 -pipe -Wall -Wpointer-arith -Wshadow -Wmissing-prototypes
-Wstrict-prototypes -o .libs/coredumper_unittest coredumper_unittest.o 
./.libs/libcoredumper.so -lpthread -Wl,--rpath
-Wl,/users/dsdeldev/Coredumper/comp/lib
creating coredumper_unittest
if icpc -DHAVE_CONFIG_H -I. -I. -I./src  -I./src   -D__64BIT__
-D__LINUX64__ -D_LP64 -g -fPIC -w1 -O3 -pipe -Wall -Wpointer-arith -Wshadow
-Wmissing-prototypes -Wstrict-prototypes -MT
linux_syscall_support_unittest.o -MD -MP -MF
".deps/linux_syscall_support_unittest.Tpo" -c -o
linux_syscall_support_unittest.o `test -f
'src/linux_syscall_support_unittest.cc' || echo
'./'`src/linux_syscall_support_unittest.cc; \
then mv -f ".deps/linux_syscall_support_unittest.Tpo"
".deps/linux_syscall_support_unittest.Po"; else rm -f
".deps/linux_syscall_support_unittest.Tpo"; exit 1; fi
src/linux_syscall_support_unittest.cc(94): error: incomplete type is not
allowed
    CHECK(sizeof(struct dirent64)  == sizeof(struct kernel_dirent64));
    ^

src/linux_syscall_support_unittest.cc(95): error: incomplete type is not
allowed
    CHECK(sizeof(struct dirent)    == sizeof(struct kernel_dirent));
    ^

src/linux_syscall_support_unittest.cc(96): error: incomplete type is not
allowed
    CHECK(sizeof(struct iovec)     == sizeof(struct kernel_iovec));
    ^

src/linux_syscall_support_unittest.cc(97): error: incomplete type is not
allowed
    CHECK(sizeof(struct msghdr)    == sizeof(struct kernel_msghdr));

etc...


This error have been found compiling with icc 9.1 20070111 on a IA64
architecture using SuSE 10


I need a solution for this compilation errors. Thanks for your time.


Best regards,
Christina.

Hello, I had been packaging coredumper and one issue comes. The file
linux/dirent.h has been removed from linux kernel hearders (at least for
fedora latest rawhide kernel).

header file defines two structs
#ifndef _LINUX_DIRENT_H
#define _LINUX_DIRENT_H

struct dirent {
        long            d_ino;
        __kernel_off_t  d_off;
        unsigned short  d_reclen;
        char            d_name[256]; /* We must not include limits.h! */
};

struct dirent64 {
        __u64           d_ino;
        __s64           d_off;
        unsigned short  d_reclen;
        unsigned char   d_type;
        char            d_name[256];
};



#endif

If you can confirm that this is not case with kernel headers and is
specially a problem for fedora kernel.

Then I will patch the package specially, but if it is other way round, then
you may consider fixing the issue.

Regards,
rakesh

I have tried to access Google group but the site was blocked in mainland China. 
If this is not the right place, would someone please forward this to project 
team and I would like to have a short discussion.
I am on a project to save as much debug info as possible and currently working 
with btrace(), register set, etc. I'd like to try coredumper on PPC system.
Thanks,
--Max

Title says it all.

What steps will reproduce the problem?
1. Use SUSE 12.3
2. ./configure
3. make

if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. 
-I./src  -I./src  -fno-omit-frame-pointer -g -O2 -MT elfcore.lo -MD -MP -MF 
".deps/elfcore.Tpo" -c -o elfcore.lo `test -f 'src/elfcore.c' || echo 
'./'`src/elfcore.c; \
then mv -f ".deps/elfcore.Tpo" ".deps/elfcore.Plo"; else rm -f 
".deps/elfcore.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -fno-omit-frame-pointer -g -O2 -MT elfcore.lo -MD -MP -MF .deps/elfcore.Tpo -c src/elfcore.c  -fPIC -DPIC -o .libs/elfcore.o
src/elfcore.c: In function 'CreatePipeline':
src/elfcore.c:1424:26: error: 'CLONE_VM' undeclared (first use in this function)
src/elfcore.c:1424:26: note: each undeclared identifier is reported only once 
for each function it appears in

I've been successfully using coredumper 1.2.1 on Sles10 (64-bit), but it 
doesn't work on Sles11 (I applied the patch to remove reliance on 
linux/dirent.h).  gdb can't analyze the stack below entry to a signal handler.  
The output from bt is 
#0  WriteCoreDump (file_name=0x407872 "core.signal.dmp") at src/coredumper.c:192
#1  0x0000000000400c47 in signalhandler () at test8.cpp:18
#2  0x00007f30010c76e0 in ?? ()
#3  0x0000000000000000 in ?? ()

Although the result from the call to WriteCoreDump(...) is success, I also find 
that somewhere errno gets set to 14 (bad address) - that didn't happen on 
Sles10.  

Is there any fix for this?  

Here's the full sequence to demonstrate the problem.
ajk@(none):/tmp/coredumper> cat test8.cpp 
const int version = 8;
#include <google/coredumper.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <signal.h>
#include <stdlib.h>
#include <sys/resource.h>

int result = 0;
int lastError = 0;
void signalhandler(int)
{
    const char* filename = "core.signal.dmp";
    errno = 0;
    result = WriteCoreDump(filename);
    lastError = errno;

}
int main(int argc, char* argv[])
{
    char* filename = argv[0];
    printf("%s Version %d\n", filename, version);

    signal(SIGRTMIN, signalhandler);

    printf("Raising SIGRTMIN\n");

    raise(SIGRTMIN);

    printf("Exiting; result = %d; last error %d:'%s'\n",
        result, errno, strerror(errno));

    return 0;
}
ajk@(none):/tmp/coredumper> g++ -Wall -ggdb test8.cpp -o dumptest8.exe 
/usr/local/lib/libcoredumper.a
ajk@(none):/tmp/coredumper> ./dumptest8.exe 
./dumptest8.exe Version 8
Raising SIGRTMIN
Exiting; result = 0; last error 14:'Bad address'
ajk@(none):/tmp/coredumper> gdb dumptest8.exe core.signal.dmp 
GNU gdb (GDB; SUSE Linux Enterprise 11) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
Core was generated by `./dumptest8.exe'.
#0  WriteCoreDump (file_name=0x407872 "core.signal.dmp") at src/coredumper.c:192
192   ClearCoreDumpParameters(&params);
(gdb) bt
#0  WriteCoreDump (file_name=0x407872 "core.signal.dmp") at src/coredumper.c:192
#1  0x0000000000400c47 in signalhandler () at test8.cpp:18
#2  0x00007f30010c76e0 in ?? ()
#3  0x0000000000000000 in ?? ()
Current language:  auto; currently c
(gdb) q
Quitting: You can't do that without a process to debug.