Bytehound - a memory profiler for Linux

Overview

Bytehound - a memory profiler for Linux

Features

  • Can be used to analyze memory leaks, see where exactly the memory is being consumed, identify temporary allocations and investigate excessive memory fragmentation
  • Gathers every allocation and deallocation, along with full stack traces
  • Can dynamically cull temporary allocations allowing you to profile over a long period of time
  • Uses a custom, tailor-made stack unwinding implementation which makes it a lot cheaper than other similar tools, potentially up to orders of magnitude faster in some cases
  • Can export the data it gathered into various different formats; it can export the data as JSON (so you can analyze it yourself if you want), as Heaptrack (so you can use the excellent Heaptrack GUI for analysis) and as a flamegraph
  • Has its own Web-based GUI which can be used for analysis
  • Can dynamically stream the profiling data to another machine instead of saving it locally, which is useful for profiling on memory-constrained systems
  • Supports AMD64, ARM, AArch64 and MIPS64 architectures (where MIPS64 requires a tiny out-of-tree kernel patch for perf_event_open)
  • Supports profiling of applications which use jemalloc as their allocator (only works on AMD64 with the jemallocator crate)
  • Supports an embedded DSL based on Rhai to allow for programmatic and/or automated data analysis

Screenshots

Building

  1. Install GCC, Rust nightly and the Yarn package manager (for building the GUI)

  2. Build it:

     $ cargo build --release -p bytehound-preload
     $ cargo build --release -p bytehound-cli
    
  3. Grab the binaries from target/release/libbytehound.so and target/release/bytehound

Usage

Basic usage

$ export MEMORY_PROFILER_LOG=warn
$ LD_PRELOAD=./libbytehound.so ./your_application
$ ./bytehound server memory-profiling_*.dat

Then open your Web browser and point it at http://localhost:8080 to access the GUI.

Documentation

You can find the full documentation for the profiler in our Memory profiling for fun and profit book.

Enabling full debug logs

By default the profiler is compiled with most of its debug logs disabled for performance reasons. To reenable them be sure to recompile it with the debug-logs feature, e.g. like this:

$ cd preload
$ cargo build --release --features debug-logs

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Issues
  • SIGSEGV when loading app with libmemory_profiler.so

    SIGSEGV when loading app with libmemory_profiler.so

    When attempting to load my application with libmemory_profiler.so in LD_PRELOAD, it immediately segfaults.

    Built with:

    rustc 1.36.0-nightly (6afcb5628 2019-05-19)
    

    Captured from GDB:

    gdb --args env LD_PRELOAD=/usr/local/lib/libmemory_profiler.so ./build/myapp
    
    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff7881e75 in memory_profiler::initialize () at preload/src/lib.rs:1239
    1239	fn initialize() {
    (gdb) bt
    #0  0x00007ffff7881e75 in memory_profiler::initialize () at preload/src/lib.rs:1239
    #1  0x00007ffff7883cc9 in memory_profiler::allocate (size=32, is_calloc=<optimized out>) at preload/src/lib.rs:1417
    #2  malloc (size=32) at preload/src/lib.rs:1459
    #3  0x00007ffff7883df6 in memory_profiler::allocate (size=32, is_calloc=<optimized out>) at preload/src/lib.rs:1429
    #4  malloc (size=32) at preload/src/lib.rs:1459
    ...
    
    opened by NuSkooler 10
  • thread '<unnamed>' panicked at 'cannot access a TLS value during or after it is destroyed: AccessError'

    thread '' panicked at 'cannot access a TLS value during or after it is destroyed: AccessError'

    On debian10 with nigthly rust

    thread '<unnamed>' panicked at 'cannot access a TLS value during or after it is destroyed: AccessError', src/libcore/result.rs:999:5
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
                 at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
       1: std::panicking::default_hook::{{closure}}
                 at src/libstd/sys_common/backtrace.rs:71
                 at src/libstd/sys_common/backtrace.rs:59
                 at src/libstd/panicking.rs:197
       2: std::panicking::rust_panic_with_hook
                 at src/libstd/panicking.rs:211
                 at src/libstd/panicking.rs:474
       3: std::panicking::continue_panic_fmt
                 at src/libstd/panicking.rs:381
       4: rust_begin_unwind
                 at src/libstd/panicking.rs:308
       5: core::panicking::panic_fmt
                 at src/libcore/panicking.rs:85
       6: core::result::unwrap_failed
                 at /rustc/37ff5d388f8c004ca248adb635f1cc84d347eda0/src/libcore/macros.rs:18
       7: memory_profiler::unwind::grab
                 at /root/.cargo/git/checkouts/not-perf-e01bfa01482c86ed/9739e8b/nwind/src/local_unwinding.rs:0
                 at preload/src/unwind.rs:166
       8: calloc
                 at preload/src/lib.rs:1423
                 at preload/src/lib.rs:1470
       9: g_malloc0
      10: g_slice_free_chain_with_offset
      11: g_queue_free
      12: __nptl_deallocate_tsd.part.8
      13: start_thread
      14: clone
    Aborted (core dumped)
    
    opened by rmanus 6
  • Build memory-profiler-cli failed

    Build memory-profiler-cli failed

    1. My environment is Ubuntu 18.04
    2. Yarn has been installed already
    3. Rust has been changed to nightly version
    4. I run "cargo build --release -p memory-profiler" suceessfully and libmemory_profiler.so has been generate already

    When I run "cargo build --release -p memory-profiler-cli", it failed and the error log as below:

    [email protected]:~/Tools/memory-profiler$ cargo build --release -p memory-profiler-cli Compiling server-core v0.1.0 (/home/davidwang/Tools/memory-profiler/server-core) 00h00m00s 0/0: : **error: failed to run custom build command for server-core v0.1.0** (/home/davidwang/Tools/memory-profiler/server-core)

    Caused by: process didn't exit successfully: /home/davidwang/Tools/memory-profiler/target/release/build/server-core-5dfb1577abf53aa3/build-script-build (exit code: 101) --- stderr ERROR: [Errno 2] No such file or directory: 'install' thread 'main' panicked at 'Failed to install the dependencies for the WebUI; child process exited with error code Some(1)! You might want to try to run 'rm -Rf ~/.cache/yarn' and try again.', server-core/build.rs:61:21 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39 1: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:71 2: std::panicking::default_hook::{{closure}} at src/libstd/sys_common/backtrace.rs:59 at src/libstd/panicking.rs:197 3: std::panicking::default_hook at src/libstd/panicking.rs:211 4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:474 5: std::panicking::continue_panic_fmt at src/libstd/panicking.rs:381 6: std::panicking::begin_panic_fmt at src/libstd/panicking.rs:336 7: semalock::Semalock::with at server-core/build.rs:61 at /home/davidwang/.cargo/registry/src/github.com-1ecc6299db9ec823/semalock-0.2.0/src/lib.rs:99 at /rustc/8869ee03d7f258e1b76a11c6fbb01b5708a9f504/src/libcore/result.rs:639 at /home/davidwang/.cargo/registry/src/github.com-1ecc6299db9ec823/semalock-0.2.0/src/lib.rs:96 8: build_script_build::main at server-core/build.rs:46 9: std::rt::lang_start::{{closure}} at /rustc/8869ee03d7f258e1b76a11c6fbb01b5708a9f504/src/libstd/rt.rs:64 10: std::panicking::try::do_call at src/libstd/rt.rs:49 at src/libstd/panicking.rs:293 11: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:85 12: std::rt::lang_start_internal at src/libstd/panicking.rs:272 at src/libstd/panic.rs:388 at src/libstd/rt.rs:48 13: main 14: __libc_start_main 15: _start

    It seems to find install dir failed, but where should the dir be?

    opened by aguludunu 5
  • Idea: Generate memory flamegraph with inferno

    Idea: Generate memory flamegraph with inferno

    Hello, maybe the most things for this are already in place and it's easy to do. Currently manual usage of the heaptrack GUI is needed to see the memory flamegraph. Inferno could be used to directly generate an interactive SVG by exporting a perf-compatible text format (the text format can even be without collapsed stacks, as there is the inferno-collapse-perf command for that).

    opened by pothos 4
  • thread_local_const_init is being stabilized

    thread_local_const_init is being stabilized

    Hi,

    Currently (on 1.59-nightly), bytehound doesn't compile because of the stabilization of thread_local_const_init feature:

    error[E0635]: unknown feature `thread_local_const_init`
     --> preload/src/lib.rs:1:12
      |
    1 | #![feature(thread_local_const_init)]
      |            ^^^^^^^^^^^^^^^^^^^^^^^
    
    For more information about this error, try `rustc --explain E0635`.
    error: could not compile `bytehound-preload` due to previous error
    

    The feature line should be removed from the code from now on I think.

    Cheers, Gerry

    opened by gagbo 3
  • Plotting memory usage of allocations from given backtrace

    Plotting memory usage of allocations from given backtrace

    Adds plots to allocations so that it's possible to tell if given backtrace is the reason for potentially visible memory leak in overview page. Improves greatly feedback regarding if backtrace is a leak or not, as one sees the trend of allocations from this backtrace - are they increasing? or maybe it was just one spike at the end of trace?

    The plot will be visible when "Group by backtraces" is selected.

    PR code is a little wonky though... but it seems to work well.

    opened by stoperro 3
  • Profiling memory usage of Go application

    Profiling memory usage of Go application

    I was thinking about using this project to compare the memory usage of a Go application that I have rewritten in Rust, but when testing the memory-profiler with a simple go example it generated no result.

    Heres the go example I've tested:

    package main
    
    import "fmt"
    import "os"
    import "strconv"
    
    func fib(n uint64) uint64 {
    	switch n {
    	case 0:
    		return 0
    	case 1:
    		return 1
    	default:
    		return fib(n-1) + fib(n-2)
    	}
    }
    
    func main() {
    	input, _ := strconv.Atoi(os.Args[1])
    	n := uint64(input)
    	fmt.Println(fib(n))
    }
    

    And running:

    go build test.go
    LD_PRELOAD=/home/jonathas/Repositories/memory-profiler/target/release/libmemory_profiler.so ./test 40
    

    Didn't generate any dat file at all. I have even tried adding a make or new calls to the fib func in order to introduce more allocations but I still got no results.

    opened by Jonathas-Conceicao 3
  • failed to run custom build command for server-core

    failed to run custom build command for server-core

    Hey, Ran into this panic when building memory-profiler-cli on Linux with rust nightly.

    error: failed to run custom build command for `server-core v0.1.0 (/home/harshasrisri/Code/memory-profiler/server-core)`
    process didn't exit successfully: `/home/harshasrisri/Code/memory-profiler/target/release/build/server-core-436551ca2cd1c07d/build-script-build` (exit code: 101)
    --- stderr
    thread 'main' panicked at 'cannot launch a child process to install the dependencies for the WebUI: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:999:5
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
                 at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
       1: std::sys_common::backtrace::_print
                 at src/libstd/sys_common/backtrace.rs:71
       2: std::panicking::default_hook::{{closure}}
                 at src/libstd/sys_common/backtrace.rs:59
                 at src/libstd/panicking.rs:197
       3: std::panicking::default_hook
                 at src/libstd/panicking.rs:211
       4: std::panicking::rust_panic_with_hook
                 at src/libstd/panicking.rs:474
       5: std::panicking::continue_panic_fmt
                 at src/libstd/panicking.rs:381
       6: rust_begin_unwind
                 at src/libstd/panicking.rs:308
       7: core::panicking::panic_fmt
                 at src/libcore/panicking.rs:85
       8: core::result::unwrap_failed
                 at /rustc/a9ec99f4201ec33026a468ef1289f98a95b4d71a/src/libcore/macros.rs:18
       9: semalock::Semalock::with
                 at /rustc/a9ec99f4201ec33026a468ef1289f98a95b4d71a/src/libcore/result.rs:827
                 at server-core/build.rs:50
                 at /home/harshasrisri/.cargo/registry/src/github.com-1ecc6299db9ec823/semalock-0.2.0/src/lib.rs:99
                 at /rustc/a9ec99f4201ec33026a468ef1289f98a95b4d71a/src/libcore/result.rs:639
                 at /home/harshasrisri/.cargo/registry/src/github.com-1ecc6299db9ec823/semalock-0.2.0/src/lib.rs:96
      10: build_script_build::main
                 at server-core/build.rs:46
      11: std::rt::lang_start::{{closure}}
                 at /rustc/a9ec99f4201ec33026a468ef1289f98a95b4d71a/src/libstd/rt.rs:64
      12: std::panicking::try::do_call
                 at src/libstd/rt.rs:49
                 at src/libstd/panicking.rs:293
      13: __rust_maybe_catch_panic
                 at src/libpanic_unwind/lib.rs:85
      14: std::rt::lang_start_internal
                 at src/libstd/panicking.rs:272
                 at src/libstd/panic.rs:388
                 at src/libstd/rt.rs:48
      15: main
      16: __libc_start_main
      17: _start
    
    warning: build failed, waiting for other jobs to finish...
    error: build failed
    
    opened by harshasrisri 3
  • Build fails on aarch64-linux-gnu

    Build fails on aarch64-linux-gnu

    rustc 1.60.0-nightly gcc (Ubuntu 9.4.0-1ubuntu1~16.04) 9.4.0 yarn 1.22.17

    Error message:

    The following warnings were emitted during compilation:
    
    warning: src/arch/aarch64_trampoline.s: Assembler messages:
    warning: src/arch/aarch64_trampoline.s:13: Error: bad register expression
    
    error: failed to run custom build command for `nwind v0.1.0 (https://github.com/koute/not-perf.git?rev=51003a4#51003a40)`
    
    Caused by:
      process didn't exit successfully: `/SD_32GB/home/cappadokesm/code/bytehound/target/release/build/nwind-85e5cfcf1e9018ce/build-script-build` (exit status: 1)
      --- stdout
      cargo:rerun-if-changed=src/arch/aarch64_get_regs.s
      cargo:rerun-if-changed=src/arch/aarch64_trampoline.s
      TARGET = Some("aarch64-unknown-linux-gnu")
      OPT_LEVEL = Some("3")
      HOST = Some("aarch64-unknown-linux-gnu")
      CC_aarch64-unknown-linux-gnu = None
      CC_aarch64_unknown_linux_gnu = None
      HOST_CC = None
      CC = None
      CFLAGS_aarch64-unknown-linux-gnu = None
      CFLAGS_aarch64_unknown_linux_gnu = None
      HOST_CFLAGS = None
      CFLAGS = None
      CRATE_CC_NO_DEFAULTS = None
      DEBUG = Some("true")
      CARGO_CFG_TARGET_FEATURE = Some("fp,neon,pmuv3")
      running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-Wall" "-Wextra" "-o" "/SD_32GB/home/cappadokesm/code/bytehound/target/release/build/nwind-bbe614d31d8d25f4/out/src/arch/aarch64_get_regs.o" "-c" "src/arch/aarch64_get_regs.s"
      exit status: 0
      running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-Wall" "-Wextra" "-o" "/SD_32GB/home/cappadokesm/code/bytehound/target/release/build/nwind-bbe614d31d8d25f4/out/src/arch/aarch64_trampoline.o" "-c" "src/arch/aarch64_trampoline.s"
      cargo:warning=src/arch/aarch64_trampoline.s: Assembler messages:
      cargo:warning=src/arch/aarch64_trampoline.s:13: Error: bad register expression
      exit status: 1
    
      --- stderr
    
    
      error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-Wall" "-Wextra" "-o" "/SD_32GB/home/cappadokesm/code/bytehound/target/release/build/nwind-bbe614d31d8d25f4/out/src/arch/aarch64_trampoline.o" "-c" "src/arch/aarch64_trampoline.s" with args "cc" did not execute successfully (status code exit status: 1).
    

    I remain at your disposal in case you need any additional information.

    Thanks a lot, X

    Edit: the above came up upon running cargo build --release -p bytehound-preload.

    opened by cappadokes 2
  • jemalloc

    jemalloc

    is there a way to use this tool with jemalloc? I set it up according to https://crates.io/crates/jemallocator. My profile file only includes a few allocations at the very beginning of the applications though. It looks like everything that was allocated with jemalloc is not captured. I am mainly interested in the memory fragmentation graph, which is why I can't just switch to the system allocator for profiling.

    opened by sklose 2
  • Problem with `gather' compilation for `i686-pc-windows-gnu'

    Problem with `gather' compilation for `i686-pc-windows-gnu'

    I got problem with linker for i686-pc-windows-gnu target. (I assume that, the linker is managed by rustup/cargo, not from system).

    after cargo build --target=i686-pc-windows-gnu (form /gather), I got:

      = note: /usr/bin/ld: unrecognized option '--enable-long-section-names'                                                                                                                                                                                                             
              /usr/bin/ld: use the --help option for usage information                                                                                                                                                                                                                   
              collect2: error: ld returned 1 exit status                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                         
                                                                                                                                                                                                                                                                                         
    error: aborting due to previous error                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                                         
    error: could not compile `memory-profiler-gather`.                                                                                                                                                                                                                                   
    

    Here goes cargo build --target=i686-pc-windows-gnu --verbose (second time) output.txt

    opened by olorin37 2
  • Filtering by time range on sub-second scale returns no results

    Filtering by time range on sub-second scale returns no results

    When filtering a timestamp from something like 2022-06-21 22:16:33.701 to 2022-06-21 22:16:33.900 the time is truncated to the nearest second, meaning all data is lost and nothing is returned.

    opened by cgbur 0
  • malloc_usable_size must return 0 for NULL

    malloc_usable_size must return 0 for NULL

    the Linux man page says:

    If ptr is NULL, 0 is returned. [...] This function is a GNU extension.

    since this is a glibc extension, bytehound should conform to the glibc specification, as other Linux replacement allocators, such as tcmalloc, jemalloc, mimalloc, and musl already do.

    opened by Hello71 0
  • Question about memory_leak_analysis

    Question about memory_leak_analysis

    In section 3, https://koute.github.io/bytehound/memory_leak_analysis.html, I try to follow your script

    let remaining = allocations().only_not_matching_backtraces(groups);
    

    Throw ERROR: Variable not found: groups (line 1, position 60) error

    So I try to filter out all of allocations previous section. But I'm not sure what is all of allocation? I have 2 options

    let groups = allocations()
        .only_leaked();
    let remaining = allocations().only_not_matching_backtraces(groups);
    

    or

    let groups = allocations()
    let remaining = allocations().only_not_matching_backtraces(groups);
    

    But I don't know which one is correct.

    opened by xluffy 0
  • 'memalign' is unimplemented! panic

    'memalign' is unimplemented! panic

    The following problem occurred today, it didn't exist before:

    thread '' panicked at 'not implemented: 'memalign' is unimplemented!', preload/src/api.rs:831:5

    opened by harlanc 0
Releases(0.8.0)
  • 0.8.0(Nov 16, 2021)

    Major changes:

    • Significantly lower CPU usage when temporary allocation culling is turned on
    • Each thread has now its own first-level backtrace cache; this might result in higher memory usage when profiling
    • The MEMORY_PROFILER_BACKTRACE_CACHE_SIZE environment variable knob was replaced with MEMORY_PROFILER_BACKTRACE_CACHE_SIZE_LEVEL_1 and MEMORY_PROFILER_BACKTRACE_CACHE_SIZE_LEVEL_2 to control the size of the per-thread caches and the global cache respectively
    • The MEMORY_PROFILER_PRECISE_TIMESTAMPS environment variable knob was removed (always gathering precise timestamps is fast enough on amd64)
    • The default value of MEMORY_PROFILER_TEMPORARY_ALLOCATION_PENDING_THRESHOLD is now unset, which means that the allocations will be buffered indefinitely until they're either culled or until they'll live long enough to not be eligible for culling (might increase memory usage in certain cases)
    • Backtraces are now not emitted for allocations which were completely culled
    • You can now see whether a given allocation was made through jemalloc, and filter according to that
    • You can now see when a given allocation group reached its maximum memory usage was, and filter according to that
    • New scripting APIs:
      • Graph::show_memory_usage
      • Graph::show_live_allocations
      • Graph::show_new_allocations
      • Graph::show_deallocations
      • AllocationList::only_group_max_total_usage_first_seen_at_least
      • AllocationList::only_jemalloc
    • New subcommand: extract (will unpack all of the files embedded into a given data file)
    • The strip subcommand will now not buffer allocations indefinitely when using the --threshold option, which results in a significantly lower memory usage when stripping huge data files from long profiling runs
    • malloc_usable_size now works properly when compiled with the jemalloc feature
    • reallocarray doesn't segfault anymore
    • The compilation should now work on distributions with an ancient version of Yarn
    Source code(tar.gz)
    Source code(zip)
    bytehound-x86_64-unknown-linux-gnu.tgz(36.15 MB)
  • 0.7.0(Aug 18, 2021)

    Major changes:

    • The project was rebranded from memory-profiler to bytehound
    • Profiling of applications using jemalloc is now fully supported (AMD64-only, jemallocator crate only)
    • Added built-in scripting capabilities which can be used for automated analysis and report generation; those can be accessed through the script subcommand
    • Added a scripting console to the GUI
    • Added the ability to define programmatic filters in the GUI
    • Allocation graphs are now shown in the GUI when browsing through the allocations grouped by backtraces
    • Improved support for tracking and analyzing reallocations
    • Improved paralellization of the analyzer's internals, which should result in snappier behavior on modern multicore machines
    • The cutoff point for determining allocations' lifetime is now the end of profiling for those allocations which were never deallocated
    • The squeeze subcommand was renamed to strip
    • You can now use the strip subcommand to strip away only a subset of temporary allocations
    • Information about allocations culled at runtime is now emitted on a per-backtrace basis during profiling
    • Fixed an issue where the shadow stack based unwinding was incompatible with Rust's ABI in certain rare cases
    • mmap calls are now always gathered in order (if you have enabled their gathering)
    • Improved runtime backtrace deduplication which should result in smaller datafiles
    • Many other miscellaneous bugfixes
    Source code(tar.gz)
    Source code(zip)
    bytehound-x86_64-unknown-linux-gnu.tgz(34.30 MB)
  • 0.6.1(Jun 10, 2021)

  • 0.6.0(Jun 9, 2021)

    Major changes:

    • Added a runtime backtrace cache; backtraces are now deduplicated when profiling, which results in less data being generated.
    • Added automatic culling of temporary allocations when running with MEMORY_PROFILER_CULL_TEMPORARY_ALLOCATIONS set to 1.
    • Added support for reallocarray.
    • Added support for unwinding through JITed code, provided the JIT compiler registers its unwinding tables through __register_frame.
    • Added support for unwinding through frames which require arbitrary DWARF expressions to be evaluated when resolving register values.
    • Added support for DWARF expressions that fetch memory.
    • Allocations are not tracked by their addresses anymore; they're now tracked by unique IDs, which fixes a race condition when multiple threads are simultaneously allocating and deallocating memory in quick succession.
    • mmap calls are now not gathered by default.
    • Rewrote TLS state management; some deallocations from TLS destructors which were previously missed by the profiler are now gathered.
    • When profiling is disabled at runtime the profiler doesn't completely shutdown anymore, and will keep on gathering data for those allocations which were made before it was disabled; when reenabled it won't create a new file anymore and instead it will keep on writing to the same file as it did before it was disabled.
    • The profiler now requires Rust nightly to compile.
    Source code(tar.gz)
    Source code(zip)
    memory-profiler-x86_64-unknown-linux-gnu.tgz(24.23 MB)
  • 0.5.0(Oct 7, 2019)

    Major changes:

    • Shadow stack based unwinding is now supported on stable Rust and turned on by default.
    • Systems where perf_event_open is unavailable (e.g. unpatched MIPS64 systems, docker containers, etc.) are now supported.
    • The mechanism for exception handling when using shadow stack based unwinding was completely rewritten using proper landing pads.
    • Programs which call longjmp/setjmp are now partially supported when using shadow stack based unwinding.
    • Shared objects dynamically loaded through dlopen are now properly handled.
    • Rust symbol demangling is now supported.
    • Fixed an issue where calling backtrace on certain architectures while using shadow stack based unwinding would crash the program.
    • The profiler can now be compiled with the jemalloc feature to use jemalloc instead of the system allocator.
    • The profiler can now be started and stopped programmatically through memory_profiler_start and memory_profiler_stop functions exported by libmemory_profiler.so. Those are equivalent to controlling the profiler through signals.
    Source code(tar.gz)
    Source code(zip)
    memory-profiler-x86_64-unknown-linux-gnu.tgz(23.39 MB)
  • 0.4.0(Jul 14, 2019)

    Major changes:

    • The profiler can now be compiled on Rust stable, with the caveat that the shadow stack based unwinding will be then disabled.
    • The profiler is now fully lazily initialized; if disabled with MEMORY_PROFILER_DISABLE_BY_DEFAULT the profiler will not initialize itself nor create an output file.
    • The signal handler registration can now be disabled with MEMORY_PROFILER_REGISTER_SIGUSR1 and MEMORY_PROFILER_REGISTER_SIGUSR2.
    • When the profiling is disabled at runtime it will more thoroughly deinitialize itself, and when reenabled it will create a new output file instead of continuing to write data to the old one.
    • The embedded server is now disabled by default and can be reenabled with the MEMORY_PROFILER_ENABLE_SERVER environment variable.
    • The base port of the embedded server can now be set with the MEMORY_PROILER_BASE_SERVER_PORT environment variable.
    • The MEMORY_PROFILER_OUTPUT now supports an %n placeholder.
    • The GUI has now a graph which shows allocations and deallocations per second.
    Source code(tar.gz)
    Source code(zip)
    memory-profiler-x86_64-unknown-linux-gnu.tgz(23.82 MB)
  • 0.3.0(Jun 6, 2019)

  • 0.2.0(May 28, 2019)

    Major changes:

    • Massive performance improvements. In the average case on AMD64 the cost per a single allocation was cut down to 20%; on ARM it was cut down to less than 50%.
    • The profiler no longer crashes when a memory operation is triggered from a destructor of an object residing in TLS.
    • The gathered timestamps are no longer as precise as they were; they should be at most off by ~250ms if your application isn't making a lot of allocations. You can restore the previous behavior if you need it by setting MEMORY_PROFILER_PRECISE_TIMESTAMPS to 1 at the cost of extra CPU time.
    Source code(tar.gz)
    Source code(zip)
    memory-profiler-x86_64-unknown-linux-gnu.tgz(24.29 MB)
Owner
Koute
Koute
Sqrt OS is a simulation of an OS scheduler and memory manager using different scheduling algorithms including Highest Priority First (non-preemptive), Shortest Remaining Time Next, and Round Robin.

A CPU scheduler determines an order for the execution of its scheduled processes; it decides which process will run according to a certain data structure that keeps track of the processes in the system and their status. A process, upon creation, has one of the three states: Running, Ready, Blocked (doing I/O, using other resources than CPU or waiting on unavailable resource).

Abdallah Hemdan 18 Apr 15, 2022
Remote Download and Memory Execute for shellcode framework

RmExecute Remote Download and Memory Execute for shellcode framework 远程下载并内存加载的ShellCode框架,暂不支持X64 参(抄)考(袭)项目 windows下shellcode提取模板的实现 主要抄袭来源,直接使用这位大佬

null 39 Jun 20, 2022
A fast image processing library with low memory needs.

libvips : an image processing library Introduction libvips is a demand-driven, horizontally threaded image processing library. Compared to similar lib

libvips 6.7k Jun 19, 2022
PoC memory injection detection agent based on ETW, for offensive and defensive research purposes

TiEtwAgent - ETW-based process injection detection This project was created to research, build and test different memory injection detection use cases

Filip Olszak 135 Jun 17, 2022
Scans all running processes. Recognizes and dumps a variety of potentially malicious implants (replaced/implanted PEs, shellcodes, hooks, in-memory patches).

Scans all running processes. Recognizes and dumps a variety of potentially malicious implants (replaced/implanted PEs, shellcodes, hooks, in-memory patches).

hasherezade 1.4k Jun 24, 2022
the checkra1n set of tools targeting bare metal, Linux and Windows

Universal toolchain Low-effort cross-compiling for the masses. What's Universal toolchain? It's a collection of sysroots and shell scripts in such a w

null 62 May 27, 2022
Linux Kernel module-less implant (backdoor)

0 KOPYCAT - Linux Kernel module-less implant (backdoor) Usage $ make $ sudo insmod kopycat.ko insmod: ERROR: could not insert module kopycat.ko: Inapp

Ilya V. Matveychikov 41 Jun 18, 2022
An asynchronous directory file change watcher module for Windows, macOS and Linux wrapped for V

A V module for asynchronously watching for file changes in a directory. The module is essentially a wrapper for septag/dmon. It works for Windows, macOS and Linux.

null 15 Jun 23, 2022
Atomically exchange two files in Linux

Atomically exchange two files in Linux.

David Pape 9 May 28, 2022
A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename.

whereami A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename. usag

Blackle Morisanchetto 1 Nov 5, 2021
Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux

Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux. Its main purpose is to help developers visualize the execution flow of a complex application.

Google 2.6k Jun 20, 2022
Minimal Linux Live (MLL) is a tiny educational Linux distribution, which is designed to be built from scratch by using a collection of automated shell scripts. Minimal Linux Live offers a core environment with just the Linux kernel, GNU C library, and Busybox userland utilities.

Minimal Linux Live (MLL) is a tiny educational Linux distribution, which is designed to be built from scratch by using a collection of automated shell scripts. Minimal Linux Live offers a core environment with just the Linux kernel, GNU C library, and Busybox userland utilities.

John Davidson 1.3k Jun 20, 2022
microprofile is an embeddable profiler

microprofile Microprofile is a embeddable profiler in a few files, written in C++ Microprofile is hosted on github: https://github.com/jonasmr/micropr

Jonas Meyer 1.2k Jun 28, 2022
Single C file, Realtime CPU/GPU Profiler with Remote Web Viewer

Remotery A realtime CPU/GPU profiler hosted in a single C file with a viewer that runs in a web browser. Supported Platforms: Windows Windows UWP (Hol

Celtoys 2.1k Jun 21, 2022
Code profiler based on Frida

Code Profiler Based on Frida This repository contains the code to profile LIEF functions with Frida. Get Started Make sure to download the right versi

LIEF 27 May 19, 2022
Palanteer is a set of high performance visual profiler, debugger, tests enabler for C++ and Python

Palanteer is a set of lean and efficient tools to improve the general software quality, for C++ and Python programs.

Damien Feneyrou 1.9k Jun 23, 2022
Optick: C++ Profiler For Games

C++ Profiler For Games

Vadim Slyusarev 2.3k Jun 18, 2022
A small program that acts as a C profiler.

Simple Performance Test Description This is a simple program in C for performance testing which only works for x86 and x86_64 systems. A for loop is e

Christian Deacon 5 May 31, 2022
Parca-agent - eBPF based always-on profiler auto-discovering targets in Kubernetes and systemd, zero code changes or restarts needed!

Parca Agent Parca Agent is an always-on sampling profiler that uses eBPF to capture raw profiling data with very low overhead. It observes user-space

Parca 150 Jun 17, 2022
A profiler to disclose and quantify hardware features on GPUs.

ArchProbe ArchProbe is a profiling tool to demythify mobile GPU architectures with great details. The mechanism of ArchProbe is introduced in our tech

Microsoft 51 May 22, 2022
Lightweight profiler library for c++

easy_profiler About Key features Usage Integration General build system CMake Inserting blocks Storing variables Collect profiling data Streaming over

Sergey Yagovtsev 1.7k Jun 27, 2022
Templight 2.0 - Template Instantiation Profiler and Debugger

Templight is a Clang-based tool to profile the time and memory consumption of template instantiations and to perform interactive debugging sessions to gain introspection into the template instantiation process.

Sven Mikael Persson 585 Jun 18, 2022
The Hoard Memory Allocator: A Fast, Scalable, and Memory-efficient Malloc for Linux, Windows, and Mac.

The Hoard Memory Allocator Copyright (C) 1998-2020 by Emery Berger The Hoard memory allocator is a fast, scalable, and memory-efficient memory allocat

Emery Berger 891 Jun 27, 2022
Custom memory allocators in C++ to improve the performance of dynamic memory allocation

Table of Contents Introduction Build instructions What's wrong with Malloc? Custom allocators Linear Allocator Stack Allocator Pool Allocator Free lis

Mariano Trebino 1.3k Jun 16, 2022
Frog is an integration of memory-based natural language processing (NLP) modules developed for Dutch. All NLP modules are based on Timbl, the Tilburg memory-based learning software package.

Frog - A Tagger-Lemmatizer-Morphological-Analyzer-Dependency-Parser for Dutch Copyright 2006-2020 Ko van der Sloot, Maarten van Gompel, Antal van den

Language Machines 69 Jun 20, 2022
A simple PoC to demonstrate that is possible to write Non writable memory and execute Non executable memory on Windows

WindowsPermsPoC A simple PoC to demonstrate that is possible to write Non writable memory and execute Non executable memory on Windows You can build i

Lorenzo Maffia 56 Jun 25, 2022
Memory Process File System (MemProcFS) is an easy and convenient way of viewing physical memory as files in a virtual file system

The Memory Process File System (MemProcFS) is an easy and convenient way of viewing physical memory as files in a virtual file system.

Ulf Frisk 1.3k Jun 23, 2022
MMCTX (Memory Management ConTeXualizer), is a tiny (< 300 lines), single header C99 library that allows for easier memory management by implementing contexts that remember allocations for you and provide freeall()-like functionality.

MMCTX (Memory Management ConTeXualizer), is a tiny (< 300 lines), single header C99 library that allows for easier memory management by implementing contexts that remember allocations for you and provide freeall()-like functionality.

A.P. Jo. 4 Oct 2, 2021
Frog is an integration of memory-based natural language processing (NLP) modules developed for Dutch. All NLP modules are based on Timbl, the Tilburg memory-based learning software package.

Frog - A Tagger-Lemmatizer-Morphological-Analyzer-Dependency-Parser for Dutch Copyright 2006-2020 Ko van der Sloot, Maarten van Gompel, Antal van den

Language Machines 68 Mar 5, 2022