codercheng / google-coredumper Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/google-coredumper
License: BSD 3-Clause "New" or "Revised" License
Automatically exported from code.google.com/p/google-coredumper
License: BSD 3-Clause "New" or "Revised" License
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
Original issue reported on code.google.com by pavel.sakov
on 12 Sep 2013 at 4:16
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 )
Original issue reported on code.google.com by [email protected]
on 3 May 2011 at 3:37
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.
Original issue reported on code.google.com by [email protected]
on 3 May 2010 at 8:23
+ 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
Original issue reported on code.google.com by [email protected]
on 21 Dec 2008 at 5:28
Attachments:
Title says it all.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2006 at 2:36
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
Original issue reported on code.google.com by [email protected]
on 18 Apr 2011 at 2:24
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.
Original issue reported on code.google.com by [email protected]
on 11 Aug 2013 at 5:23
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
Original issue reported on code.google.com by [email protected]
on 16 Jun 2015 at 2:33
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
Original issue reported on code.google.com by [email protected]
on 19 Mar 2015 at 11:15
Attachments:
$ 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)
Original issue reported on code.google.com by [email protected]
on 25 Dec 2012 at 9:18
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
Original issue reported on code.google.com by [email protected]
on 20 Apr 2009 at 10:59
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.
Original issue reported on code.google.com by [email protected]
on 17 Nov 2011 at 8:18
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 19 Feb 2014 at 8:34
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(¶ms);
(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.
Original issue reported on code.google.com by [email protected]
on 21 Jan 2011 at 11:25
There are no tags in the svn repository. There should be tags exactly
recording what went into any particular versioned release.
Original issue reported on code.google.com by [email protected]
on 1 Oct 2008 at 2:15
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
Original issue reported on code.google.com by [email protected]
on 1 Oct 2008 at 2:19
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
Original issue reported on code.google.com by [email protected]
on 25 Aug 2008 at 5:06
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.
Original issue reported on code.google.com by [email protected]
on 1 Jul 2014 at 3:28
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.