vmware / chap Goto Github PK
View Code? Open in Web Editor NEWchap analyzes un-instrumented core files for leaks, memory growth, and corruption
License: Other
chap's People
Contributors
Stargazers
Watchers
Forkers
mzeren-vmw pramodk-vmw georgi-d gdimitrov-vmware chubbymaggie incnb weimingtom digitumdei feicc alexxnica kryndex wangjieboy leslieuc spurnaye rohanverma94 silvercreekpk bingyi bsmr liwei-rk leonid3000 bruce1634 ibuystuff samsaffron jrjang heruix stepets pankaj161982 zhigao gdlynx emptywatson ekmixon sound1992 rangani clayne rnshah9 bumdria1 alvingreat josephch isabella232 seanpm2001chap's Issues
printing partially when showing leaked
Hi,
I have a huge coredump file.
When loaded into chap, command "show leaked" will take more than 5 minute.
I wonder if there is a command for "show leaked" page by page, and by pressing space to continue showing the next page of leaked memory
Thank you!
Can't clone the repository onto an NTFS drive
I can't clone the repository onto an NTFS drive.
Here's what happens:
Cloning into 'chap'...
remote: Enumerating objects: 30, done.
remote: Counting objects: 100% (30/30), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 2507 (delta 9), reused 16 (delta 7), pack-reused 2477
Receiving objects: 100% (2507/2507), 52.77 MiB | 17.40 MiB/s, done.
Resolving deltas: 100% (1628/1628), done.
error: unable to create file test/expectedOutput/ELF32/LibcMalloc/LongStringTest/core.26548.list_used::extend:->%LongString=>StopHere::minoutgoing:%LongString=1: Invalid argument
error: unable to create file test/expectedOutput/ELF32/LibcMalloc/LongStringTest/core.26548.list_used::minoutgoing:%LongString=1: Invalid argument
error: unable to create file test/expectedOutput/ELF64/LibcMalloc/HasContainersAndSymbols/core.38066.count_used::extend:->: Invalid argument
error: unable to create file test/expectedOutput/ELF64/LibcMalloc/HasContainersAndSymbols/core.38066.count_used::extend:
...
This happens because of special characters like > in filenames, which are reserved.
Chep complains a slate build environment and requires a rebuild
Describe the bug
Your chap binary was compiled using a stale build environment that generates
invalid std::regex code. Upgrade your build environment and remake chap.
My cmake is 3.17.5, gcc is 4.8.5. Linux: Centos 7.9 Which one is too old?
Reproduction steps
1. ./chap `ls -t core.* | head -1`
2.
3.
...Expected behavior
Tell us the lowest version that is suported.
Additional context
No response
Controlling chap with python/externally
Is your feature request related to a problem? Please describe.
No problem.
Describe the solution you'd like
How can I control chap programatically? For example, I can start it with python, but would like issue commands automatically.
What is the best approach for this, if any exists?
Describe alternatives you've considered
No response
Additional context
No response
Command completion is missing a few commands
Command completion does not yet support any commands that are not set based. Some commands that are not set based include "help", "source" and "redirect".
NULL pointer dereference in chap::Linux::ELFImage
Hello.
I found a NULL pointer dereference in chap.
Please confirm.
Thanks.
Summary: NULL pointer dereference
OS: CentOS 7 64bit
Version: commit 982c9d9
PoC Download: null_ELFImage.zip
Steps to reproduce:
1.Download the .POC files.
2.Execute the following command
: ./chap $PoC
==21537== Invalid read of size 1
==21537== at 0x430DBE: chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo>::VisitNotes(std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, unsigned int)>) (ELFImage.h:264)
==21537== by 0x43022B: chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo>::ELFImage(chap::FileImage const&) (ELFImage.h:184)
==21537== by 0x42FCA0: chap::Linux::ELFCoreFileAnalyzer<chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo> >::ELFCoreFileAnalyzer(chap::FileImage const&, bool) (ELFCoreFileAnalyzer.h:18)
==21537== by 0x42FC0E: chap::Linux::ELFCore64FileAnalyzerFactory::MakeFileAnalyzer(chap::FileImage const&, bool) (ELFCore64FileAnalyzerFactory.h:24)
==21537== by 0x42C918: main (FileAnalyzer.cpp:70)
==21537== Address 0x4a50c58a is not stack'd, malloc'd or (recently) free'd
==21537==
==21537==
==21537== Process terminating with default action of signal 11 (SIGSEGV)
==21537== Access not within mapped region at address 0x4A50C58A
==21537== at 0x430DBE: chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo>::VisitNotes(std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, unsigned int)>) (ELFImage.h:264)
==21537== by 0x43022B: chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo>::ELFImage(chap::FileImage const&) (ELFImage.h:184)
==21537== by 0x42FCA0: chap::Linux::ELFCoreFileAnalyzer<chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo> >::ELFCoreFileAnalyzer(chap::FileImage const&, bool) (ELFCoreFileAnalyzer.h:18)
==21537== by 0x42FC0E: chap::Linux::ELFCore64FileAnalyzerFactory::MakeFileAnalyzer(chap::FileImage const&, bool) (ELFCore64FileAnalyzerFactory.h:24)
==21537== by 0x42C918: main (FileAnalyzer.cpp:70)
==21537==
==========
[Acknowledgement]
This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001, Innovation hub for high Performance Computing]
Use-after-free reported when compiled with Address Sanitizer
When built with address sanitizer, the compiled chap executable emits a heap-use-after-free when testing against a binary core dump file generated from Quick Start.
=================================================================
==28175==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000000ba8 at pc 0x0000004a2938 bp 0x7ffe450b5150 sp 0x7ffe450b4900
READ of size 889192450 at 0x604000000ba8 thread T0
#0 0x4a2937 in memcpy /home/haijun/Tools/llvm-5.0/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:738
#1 0x7f6ca3f8a4ab in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xc64ab)
#2 0x7f6ca3f8ab6b in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xc6b6b)
#3 0x6a0717 in std::pair<std::string, chap::Allocations::PatternRecognizer<unsigned long>*>::pair<chap::Allocations::PatternRecognizer<unsigned long>*&, true>(std::string const&, chap::Allocations::PatternRecognizer<unsigned long>* &) /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_pair.h:315:10
#4 0x6a0717 in std::pair<std::__decay_and_strip<std::string const&>::__type, std::__decay_and_strip<chap::Allocations::PatternRecognizer<unsigned long>*&>::__type> std::make_pair<std::string const&, chap::Allocations:: PatternRecognizer<unsigned long>*&>(std::string const&, chap::Allocations::PatternRecognizer<unsigned long>*&) /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_pair.h:524
#5 0x6a0717 in chap::Allocations::PatternRecognizerRegistry<unsigned long>::Register(chap::Allocations::PatternRecognizer<unsigned long>*) /home/hongxu/chap/src/Allocations/Subcommands/../PatternRecognizerRegistry.h:41
#6 0x69a9b6 in chap::ProcessImageCommandHandler<unsigned long>::ProcessImageCommandHandler(chap::ProcessImage<unsigned long> const*) /home/hongxu/chap/src/Linux/../ProcessImageCommandHandler.h:52:32
#7 0x53bf2d in chap::Linux::ProcessImageCommandHandler<unsigned long>::ProcessImageCommandHandler(chap::ProcessImage<unsigned long> const*) /home/hongxu/chap/src/Linux/ProcessImageCommandHandler.h:19:9
#8 0x537f9b in chap::Linux::ELFCoreFileAnalyzer<chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo> >::ELFCoreFileAnalyzer(chap:: FileImage const&, bool) /home/hongxu/chap/src/Linux/ELFCoreFileAnalyzer.h:26:17
#9 0x537b0f in chap::Linux::ELFCore64FileAnalyzerFactory::MakeFileAnalyzer(chap::FileImage const&, bool) /home/hongxu/chap/src/Linux/ELFCore64FileAnalyzerFactory.h:24:18
#10 0x52ad3c in main /home/hongxu/chap/src/FileAnalyzer.cpp:70:18
#11 0x7f6ca2fd4f44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
#12 0x41d9a4 in _start (/home/hongxu/chap/FOT/chap+0x41d9a4)
0x604000000bb3 is located 0 bytes to the right of 35-byte region [0x604000000b90,0x604000000bb3)
freed by thread T0 here:
#0 0x5269c0 in operator delete(void*) /home/haijun/Tools/llvm-5.0/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:137
#1 0x6bf3f0 in std::string::_Rep::_M_dispose(std::allocator<char> const&) /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/basic_string.h:3251:5
#2 0x6bf3f0 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/basic_string.h:3621
#3 0x6bf3f0 in chap::VectorBodyRecognizer<unsigned long>::VectorBodyRecognizer(chap::ProcessImage<unsigned long> const*) /home/hongxu/chap/src/VectorBodyRecognizer.h:17
#4 0x69a9a7 in chap::ProcessImageCommandHandler<unsigned long>::ProcessImageCommandHandler(chap::ProcessImage<unsigned long> const*) /home/hongxu/chap/src/Linux/../ProcessImageCommandHandler.h:53:13
#5 0x53bf2d in chap::Linux::ProcessImageCommandHandler<unsigned long>::ProcessImageCommandHandler(chap::ProcessImage<unsigned long> const*) /home/hongxu/chap/src/Linux/ProcessImageCommandHandler.h:19:9
#6 0x537f9b in chap::Linux::ELFCoreFileAnalyzer<chap::Linux::ELFImage<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, Elf64_Nhdr, unsigned long, unsigned int, (unsigned char)2, chap::Linux::ELF64PRStatusRegInfo> >::ELFCoreFileAnalyzer(chap:: FileImage const&, bool) /home/hongxu/chap/src/Linux/ELFCoreFileAnalyzer.h:26:17
#7 0x537b0f in chap::Linux::ELFCore64FileAnalyzerFactory::MakeFileAnalyzer(chap::FileImage const&, bool) /home/hongxu/chap/src/Linux/ELFCore64FileAnalyzerFactory.h:24:18
previously allocated by thread T0 here:
#0 0x525c48 in operator new(unsigned long) /home/haijun/Tools/llvm-5.0/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:92
#1 0x7f6ca3f89618 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xc5618)
#2 0x6270000017e7 (<unknown module>)
SUMMARY: AddressSanitizer: heap-use-after-free /home/haijun/Tools/llvm-5.0/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:738 in memcpy
Shadow bytes around the buggy address:
0x0c087fff8120: fa fa 00 00 00 00 00 05 fa fa 00 00 00 00 00 01
0x0c087fff8130: fa fa 00 00 00 00 00 05 fa fa 00 00 00 00 00 03
0x0c087fff8140: fa fa 00 00 00 00 00 07 fa fa 00 00 00 00 01 fa
0x0c087fff8150: fa fa 00 00 00 00 06 fa fa fa 00 00 00 00 01 fa
0x0c087fff8160: fa fa 00 00 00 00 05 fa fa fa 00 00 00 00 05 fa
=>0x0c087fff8170: fa fa fd fd fd[fd]fd fa fa fa fa fa fa fa fa fa
0x0c087fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff81a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==28175==ABORTING
$ clang --version
clang version 5.0.0 (tags/RELEASE_500/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ uname -a
Linux csl-02 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
showing code lines
Hi chap team,
how can I enable showing the infected code lines ?
is it possible ?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.