Palanteer is a set of high performance visual profiler, debugger, tests enabler for C++ and Python

Overview

Look into Palanteer and get an omniscient view of your program

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

Simple code instrumentation, mostly automatic in Python, delivers powerful features:

  • Collection of meaningful atomic events on timings, memory, locks wait and usage, context switches, data values..
  • Visual and interactive observation of record: timeline, plot, histograms, flame graph, ...
  • Remote command call and events observation can be scripted in Python: deep testing has never been simpler
  • C++:
    • ultra-light single-header cross-platform instrumentation library
    • compile-time selection of groups of instrumentation
    • compile-time hashing of static string to minimize their cost
    • compile-time striping of all instrumentation static strings
    • enhanced assertions, stack trace dump...
  • Python:
    • Automatic instrumentation of functions enter/leave, memory allocations, raised exceptions, garbage collection runs

Palanteer viewer image

Palanteer is an efficient, lean and comprehensive solution for better and enjoyable software development!

C++ instrumentation example

Below is a simple example of a C++ program instrumented with Palanteer and generating 100 000 random integers. The range can be remotely configured with a user-defined CLI.

The Python scripting module can control this program, in particular:

  • call the setBoundsCliHandler to change the configuration
  • temporarily stop the program at the freeze point
  • see all "random data" values and the timing of the scope event "Generate some random values"
maxValue) { // Case where the CLI execution fails. The text answer contains some information about it cio.setErrorState("Minimum value (%d) shall be lower than the maximum value (%d)", minValue, maxValue); return; } // Modify the state of the program. No care about thread-safety here, to keep the example simple globalMinValue = minValue; globalMaxValue = maxValue; // CLI execution was successful (because no call to cio.setErrorState()) } int main(int argc, char** argv) { plInitAndStart("example"); // Start the instrumentation, for the program named "example" plDeclareThread("Main"); // Declare the current thread as "Main" so that it can be identified more easily in the script plRegisterCli(setBoundsCliHandler, "config:setRange", "min=int max=int", "Sets the value bounds of the random generator"); // Declare our CLI plFreezePoint(); // Add a freeze point here to be able to configure the program at a controlled moment plBegin("Generate some random values"); for(int i=0; i<100000; ++i) { int value = globalMinValue + rand()%(globalMaxValue+1-globalMinValue); plData("random data", value); // Here are the "useful" values } plEnd(""); // Shortcut for plEnd("Generate some random values") plStopAndUninit(); // Stop and uninitialize the instrumentation return 0; } ">
// File: example.cpp
// On Linux, build with:  g++ -DUSE_PL=1 -I  example.cpp -lpthread -o example
#include <stdlib.h>          // For "rand"
#define PL_IMPLEMENTATION 1  // The instrumentation library shall be "implemented" once
#include "palanteer.h"

int globalMinValue = 0, globalMaxValue = 10;

// Handler (=user implementation) of the example CLI, which sets the range
void setBoundsCliHandler(plCliIo& cio)             // 'cio' is a communication helper passed to each C++ CLI handler
{
    int minValue = cio.getParamInt(0);             // Get the 2 CLI parameters as integers (as declared)
    int maxValue = cio.getParamInt(1);
    if(minValue>maxValue) {                        // Case where the CLI execution fails. The text answer contains some information about it
        cio.setErrorState("Minimum value (%d) shall be lower than the maximum value (%d)", minValue, maxValue);
        return;
    }

    // Modify the state of the program. No care about thread-safety here, to keep the example simple
    globalMinValue = minValue;
    globalMaxValue = maxValue;
    // CLI execution was successful (because no call to cio.setErrorState())
}


int main(int argc, char** argv)
{
    plInitAndStart("example");              // Start the instrumentation, for the program named "example"
    plDeclareThread("Main");                // Declare the current thread as "Main" so that it can be identified more easily in the script
    plRegisterCli(setBoundsCliHandler, "config:setRange", "min=int max=int", "Sets the value bounds of the random generator");  // Declare our CLI
    plFreezePoint();                        // Add a freeze point here to be able to configure the program at a controlled moment

    plBegin("Generate some random values");
    for(int i=0; i<100000; ++i) {
        int value = globalMinValue + rand()%(globalMaxValue+1-globalMinValue);
        plData("random data", value);       // Here are the "useful" values
    }
    plEnd("");                              // Shortcut for plEnd("Generate some random values")

    plStopAndUninit();                      // Stop and uninitialize the instrumentation
    return 0;
}

Some C++ performance figures (see here for more details):

  • nanosecond resolution and ~25 nanoseconds cost per event on a standard x64 machine
  • up to ~3 millions events per second when recording, the bottleneck being on the server processing side
  • up to ~150 000 events per second when processing the flow through a Python script, the bottleneck being on the Python script side

More details and an example of remote script is provided here

Python instrumentation example

Execution of unmodified Python programs can be analyzed directly with a syntax similar to the one of cProfile, as a large part of the instrumentation is automated by default:

  • Functions enter/leave
  • Interpreter memory allocations
  • All raised exceptions
  • Garbage collection runs

In some cases, a manual instrumentation which enhances or replaces the automatic one is desired.
The example below is such an equivalent of the C++ one above but in Python:

#! /usr/bin/env python3
import sys
import random
from palanteer import *

globalMinValue, globalMaxValue =  0, 10

# Handler (=implementation) of the example CLI, which sets the range
def setBoundsCliHandler(minValue, maxValue):              # 2 parameters (both integer) as declared
    global globalMinValue, globalMaxValue
    if minValue>maxValue:                                 # Case where the CLI execution fails (non null status). The text answer contains some information about it
        return 1, "Minimum value (%d) shall be lower than the maximum value (%d)" % (minValue, maxValue)

    # Modify the state of the program
    globalMinValue, globalMaxValue = minValue, maxValue
    # CLI execution was successful (null status)
    return 0, ""


def main(argv):
    global globalMinValue, globalMaxValue

    plInitAndStart("example")                             # Start the instrumentation
    plDeclareThread("Main")                               # Declare the current thread as "Main", so that it can be identified more easily in the script
    plRegisterCli(setBoundsCliHandler, "config:setRange", "min=int max=int", "Sets the value bounds of the random generator")  # Declare the CLI
    plFreezePoint()                                       # Add a freeze point here to be able to configure the program at a controlled moment

    plBegin("Generate some random values")
    for i in range(100000):
        value = int(globalMinValue + random.random()*(globalMaxValue+1-globalMinValue))
        plData("random data", value)                      # Here are the "useful" values
    plEnd("")                                             # Shortcut for plEnd("Generate some random values")

    plStopAndUninit()                                     # Stop and uninitialize the instrumentation

# Bootstrap
if __name__ == "__main__":
    main(sys.argv)

More details and an example of remote script, the same as for the C++ example, is provided here

Documentation

The complete documentation is accessible inside the repository, and online:

Requirements

Palanteer is lean, its full installation requires only usual components:

  • a C++14+ compiler (gcc, clang or MSVC) in Windows 10 or Linux 64 bits for the viewer and scripting module
  • a C++11+ compiler (tested with gcc, clang and MSVC) 32 or 64 bits for the C++ instrumentation library
  • CPython 3.7+
  • OpenGL 3.3+

In particular, the C++ single-header instrumentation library requires only C++11 or above.

See here for more details on the requirements per component.

Other dependencies are snapshotted inside this repository, so for information only:

Dependency name License type URL
Khronos OpenGL API and Extension MIT https://www.khronos.org/registry/OpenGL/api/GL
Dear ImGui MIT https://github.com/ocornut/imgui
stb_image Public domain https://github.com/nothings/stb
Fonts 'Roboto-Medium.ttf' Apache License, Version 2.0 https://fonts.google.com/specimen/Roboto
ZStandard BSD https://facebook.github.io/zstd
Markdeep BSD https://casual-effects.com/markdeep

License

The instrumentation libraries are under the MIT license.

The viewer and the Python scripting module are under the AGPLv3+.

See LICENSE.md for details.

Warning: Beta state

Even if no major bugs are known and a special care has been taken to test as many cases as possible, this project is young and in beta state.

Your feedback and raised issues are warmly welcome to improve its quality, especially as it aims at improving software quality...

Issues
  • Crash when trying to instrument a program on current git master

    Crash when trying to instrument a program on current git master

    Linux x64: as soon as I launch the app to profile, the GUI crashes with:

    [PALANTEER] Assertion failed: _underRecordRecIdx>=0
      On function: void vwMain::draw()
      On file    : /home/jcelerier/projets/perso/lafajol/3rdparty/palanteer/server/viewer/vwMain.cpp(357)
        - int     _underRecordRecIdx   = -1
    
      #0  0x55AE269C7652 : _ZN6vwMain4drawEv
      #1  0x55AE26A59C37 : _ZN10vwPlatform6redrawEv
      #2  0x55AE26A59D29 : _ZN10vwPlatform3runEv
      #3  0x55AE26A5A80B : _Z11bsBootstrapiPPc
      #4  0x7F560497130C : __libc_start_call_main
      #5  0x7F56049713BD : [email protected]@GLIBC_2.34
      #6  0x55AE269449D1 : _start
    
    opened by jcelerier 15
  • Possible race condition leading to access to NULL pointer

    Possible race condition leading to access to NULL pointer

    This might have been partly due to overflow, as I saw buffer saturation previously. Either case, the race condition seems to be there.

    On commit: fd6a6a3e0914eae579216ab43793bd5dc62c53cf Compiler: gcc 9.3.0 with -g -O0 --std=c++20 You can hopefully reproduce it using the exact code, though I haven't exhaustively tested it (should work on x86_64, but who knows, it's way too hacky right now). https://github.com/NetPunkSoftware/Fibers/commit/405d493cf4199a0b34a966b86a6a51def8417f0f

    It happens about 3 out of every 5 executions.


    Now, into what I believe is a race condition. See the following two stack traces:

    Thread 1:

    plPriv::hashString(const char * s, int maxCharQty) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1460)
    plPriv::collectEvents(bool doForce) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:3485)
    plPriv::transmitToServer() (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:3874)
    std::__invoke_impl<void, void (*)()>(void (*&&)(void) __f) (/usr/include/c++/11/bits/invoke.h:61)
    std::__invoke<void (*)()>(void (*&&)(void) __fn) (/usr/include/c++/11/bits/invoke.h:96)
    std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul>(std::thread::_Invoker<std::tuple<void (*)()> > * const this) (/usr/include/c++/11/bits/std_thread.h:253)
    std::thread::_Invoker<std::tuple<void (*)()> >::operator()(std::thread::_Invoker<std::tuple<void (*)()> > * const this) (/usr/include/c++/11/bits/std_thread.h:260)
    std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run(std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > > * const this) (/usr/include/c++/11/bits/std_thread.h:211)
    libstdc++.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0)
    libpthread.so.0!start_thread(void * arg) (/home/build/YPKG/root/glibc/build/glibc.git/nptl/pthread_create.c:481)
    libc.so.6!clone() (/home/build/YPKG/root/glibc/build-avx2/glibc.git/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
    

    Particularly plPriv::collectEvents at palanteer-src/c++/palanteer.h:3485. The current even being iterated, src, points to 0x7ffff70af990.

    Other variables of possible interest (at collectEvents):

    evtIdx = 12901
    eventQty = 20036
    globalCtx.prevBankAndIndex = 20036
    

    Now, Thread 2:

    plPriv::eventLogBase(uint32_t bi, plPriv::hashStr_t filenameHash_, plPriv::hashStr_t nameHash_, const char * filename_, const char * name_, int lineNbr_, int flags_) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1545)
    plPriv::eventLogRaw(plPriv::hashStr_t filenameHash_, plPriv::hashStr_t nameHash_, const char * filename_, const char * name_, int lineNbr_, bool doSkipOverflowCheck_, int flags_, plPriv::bigRawData_t v) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1565)
    plPriv::TimedScope::~TimedScope(plPriv::TimedScope * const this) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1825)
    np::fiber_pool_base::worker_thread(np::fiber_pool_base * const this, uint8_t idx) (/home/guillem/Github/Fibers/src/pool/fiber_pool.cpp:171)
    std::__invoke_impl<void, void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int>(std::__invoke_memfun_deref, void (np::fiber_pool_base::*&&)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*&&, int&&)(void (np::fiber_pool_base::*&&)(np::fiber_pool_base * const, unsigned char) __f, np::fiber_pool<np::detail::default_fiber_pool_traits> *&& __t) (/usr/include/c++/11/bits/invoke.h:74)
    std::__invoke<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int>(void (np::fiber_pool_base::*&&)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*&&, int&&)(void (np::fiber_pool_base::*&&)(np::fiber_pool_base * const, unsigned char) __fn) (/usr/include/c++/11/bits/invoke.h:96)
    std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> >::_M_invoke<0ul, 1ul, 2ul>(std::_Index_tuple<0ul, 1ul, 2ul>)(std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > * const this) (/usr/include/c++/11/bits/std_thread.h:253)
    std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> >::operator()()(std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > * const this) (/usr/include/c++/11/bits/std_thread.h:260)
    std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > >::_M_run()(std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > > * const this) (/usr/include/c++/11/bits/std_thread.h:211)
    libstdc++.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0)
    libpthread.so.0!start_thread(void * arg) (/home/build/YPKG/root/glibc/build/glibc.git/nptl/pthread_create.c:481)
    libc.so.6!clone() (/home/build/YPKG/root/glibc/build-avx2/glibc.git/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
    

    The last call, plPriv::eventLogBase, at palanteer-src/c++/palanteer.h:1545, is writing an event. Uppon inspection, e has the same address 0x7ffff70af990. It has crashed short of writing the string itself, which would have been the next line. At the moment of the crash, e.nameHash == 0 and e.name == 0.

    Other variables of possible interest (at eventLogBase):

    bi = 12901
    

    If this is caused due to me going well beyond the acceptable buffer size, maybe we could introduce some assertion during debug, so that it triggers instead of causing UB.

    Otherwise, I see two ways of going over this:

    1. Adding a local ready atomic to each event, so that the consumer must spin/yield until it is flagged by the producer.

    2. Using two pointers to the buffer, so that one points to the last valid position (ie. written and valid) and the another one points to the last writable position (ie. free and not being used).

    bug C++ instrumentation 
    opened by gpascualg 7
  • Consistent crashes when navigating to some directories with the import file dialog

    Consistent crashes when navigating to some directories with the import file dialog

    Here, https://github.com/dfeneyrou/palanteer/blob/main/server/viewer/vwFileDialog.cpp#L203-L204

    I consistently get a EXC_I386_GPFLT (general protection fault) on a.name.toChar() when navigating to certain directories. I can iterate and print the names of all elements in _fileEntries without issue, so I imagine that std::sort is doing something undesirable in conjunction with your string library. Unfortunately I'm not really sure how best to debug this issue, and I haven't found anything particularly special about the failing directories.

    bug 
    opened by jceipek 6
  • MSVC 2022: C++ library build broken with UNICODE

    MSVC 2022: C++ library build broken with UNICODE

    When trying to build the c++ library while having UNICODE declared, the following error occurs:

    palanteer-src\c++\palanteer.h(4346,53): error C2440: '=': cannot convert from 'const wchar_t [17]' to 'LPWSTR'
    

    Basically, in that line, LogFile.LoggerName = KERNEL_LOGGER_NAME; the structure field expects a non-const value, while KERNEL_LOGGER_NAME is const. I have worked around it by casting it to (LPWSTR). I don't know the API exactly, so it feels like a hack to cast it to non-constness.

    - LogFile.LoggerName          = KERNEL_LOGGER_NAME;
    + #if defined(_UNICODE) || defined(UNICODE)
    + LogFile.LoggerName          = (LPWSTR)KERNEL_LOGGER_NAME;
    + #else
    + LogFile.LoggerName          = KERNEL_LOGGER_NAME;
    + #endif
    
    bug question C++ instrumentation 
    opened by gpascualg 5
  • MSVC 2022: Run-Time Check Failure #3 - The variable 'prevE' is being used without being initialized.

    MSVC 2022: Run-Time Check Failure #3 - The variable 'prevE' is being used without being initialized.

    Checked out at: e305d17585eb2188896ed0c2d7cc0913947dd399

    When zooming a timeline in, either in a live view or record that uses fibers, visual studio complains of an access to an initialized variable.

    palanteer.exe!vwMain::prepareTimeline(vwMain::Timeline & tl) Line 1150 C++ palanteer.exe!vwMain::drawTimeline(int tlWindowIdx) Line 1478 C++ palanteer.exe!vwMain::drawTimelines() Line 1432 C++ palanteer.exe!vwMain::draw() Line1149 C++ palanteer.exe!vwPlatform::redraw() Line 365 C++ palanteer.exe!vwPlatform::run() Line 304 C++ palanteer.exe!bsBootstrap(int argc, char * * argv) Line 200 C++ palanteer.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 780 C++

    I would submit a PR (proposed change at the bottom), but I suspect there is something more, as by the looks of it and the variable name, prevE should probably never be used during the first iteration.

    vwMainTimeline.cpp:1138

    - cmRecord::Evt prevE, e; prevE.nameIdx = PL_INVALID;
    + cmRecord::Evt prevE, e; prevE.nameIdx = PL_INVALID; prevE.flags = 0x0;
    
    bug viewer 
    opened by gpascualg 4
  • How to start service (so thread/fiber registration works) but not start recording yet?

    How to start service (so thread/fiber registration works) but not start recording yet?

    I've been trying the fiber integration as per your helpful Gist from a while back (https://gist.github.com/dfeneyrou/8f8aa2956dcb32e0860665c610d7bb2f).

    I was following my usage pattern of Optick, where I didn't start profiling from the beginning but instead triggered it via a debug menu. However, my FTL Task Scheduler is created at the beginning, and its creation invokes the callbacks shown in the above Gist. Because of this, the calls to e.g. plDeclareVirtualThread take place before the call to plInitAndStart, and so in the profiler itself none of that information is shown.

    Am I able to somehow start up the service at the beginning so that these registrations are accepted, but not start any kind of recording / transmission to the Palanteer application until later? I know there's PL_MODE_INACTIVE, but as far as I can see, the mode can't be changed after the init call?

    I'll have to try calling plInitAndStart at game start, creating my scheduler and having the FTL callbacks fire, then immediately calling plStopAndUninit, and then calling init again later when I want to actually profile. Bit messy though and not sure if it works right.

    EDIT: Looks like init-stop-init isn't the solution; not surprised.

    image

    bug enhancement 
    opened by BrodyHiggerson 2
  • Make `pip install palanteer` possible

    Make `pip install palanteer` possible

    Hello guys,

    Thanks for your contribution. palanteer seems really cool. I have to give it a shot to see what it has to offer.

    I am proposing that you would consider publishing your package in the PyPi registry so that python developers would be able to install it using pip.

    Keep up the good work and stay awesome. 🥂

    opened by meysam81 2
  • Building broken on Linux - permission denied

    Building broken on Linux - permission denied

    [email protected] ~/g/p/build (main) [1]> cmake .. -DCMAKE_INSTALL_PREFIX=/opt/palanteer
    -- The C compiler identification is GNU 9.3.0
    -- The CXX compiler identification is GNU 9.3.0
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /usr/bin/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /usr/bin/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    Build type: Release   (change with -DCMAKE_BUILD_TYPE=<Debug|Release|RelWithDebInfo|MinSizeRel|Asan>)
    -- Looking for pthread.h
    -- Looking for pthread.h - found
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
    -- Check if compiler accepts -pthread
    -- Check if compiler accepts -pthread - yes
    -- Found Threads: TRUE  
    -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so   
    -- Found X11: /usr/include   
    -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
    -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
    -- Looking for gethostbyname
    -- Looking for gethostbyname - found
    -- Looking for connect
    -- Looking for connect - found
    -- Looking for remove
    -- Looking for remove - found
    -- Looking for shmat
    -- Looking for shmat - found
    -- Looking for IceConnectionNumber in ICE
    -- Looking for IceConnectionNumber in ICE - found
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBUNWIND)
      does not match the name of the calling package (LibUnwind).  This can lead
      to problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibUnwind.cmake:23 (find_package_handle_standard_args)
      server/viewer/CMakeLists.txt:29 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Found LIBUNWIND: /usr/lib/x86_64-linux-gnu/libunwind.so  
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBDW) does
      not match the name of the calling package (LibDw).  This can lead to
      problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibDw.cmake:23 (find_package_handle_standard_args)
      server/viewer/CMakeLists.txt:30 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Found LIBDW: /usr/lib/x86_64-linux-gnu/libdw.so  
    Palanteer feature 'stacktrace' enabled for viewer
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBUNWIND)
      does not match the name of the calling package (LibUnwind).  This can lead
      to problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibUnwind.cmake:23 (find_package_handle_standard_args)
      c++/testprogram/CMakeLists.txt:24 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBDW) does
      not match the name of the calling package (LibDw).  This can lead to
      problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibDw.cmake:23 (find_package_handle_standard_args)
      c++/testprogram/CMakeLists.txt:25 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    Palanteer feature 'stacktrace' enabled for testprogram
    -- Found Python3: /usr/bin/python3.8 (found version "3.8.5") found components: Interpreter 
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/bareya/git/palanteer/build
    [email protected] ~/g/p/build (main)> make 
    Scanning dependencies of target palanteer
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwConfig.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwConst.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwFileDialog.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwFontData.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMain.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainCommon.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainHistogram.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainMarker.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainMemory.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainPlot.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainProfile.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainRecordCatalog.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainSearch.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainText.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainTimeline.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwPlatform.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwReplayAlloc.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmCnx.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmCompress.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmLiveControl.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmRecord.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmRecordIterator.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmRecording.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsGlHelper.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsOsLinux.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsOsWindows.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsString.cpp.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/debug.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/entropy_common.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/error_private.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/fse_decompress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/pool.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/threading.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/xxhash.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/zstd_common.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/fse_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/hist.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/huf_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress_literals.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress_sequences.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress_superblock.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_double_fast.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_fast.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_lazy.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_ldm.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_opt.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstdmt_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/huf_decompress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/zstd_ddict.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/zstd_decompress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/zstd_decompress_block.c.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui_draw.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui_tables.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui_widgets.cpp.o
    [100%] Linking CXX executable ../../bin/palanteer
    [100%] Built target palanteer
    Scanning dependencies of target testprogram
    [100%] Building CXX object c++/testprogram/CMakeFiles/testprogram.dir/testProgram.cpp.o
    [100%] Building CXX object c++/testprogram/CMakeFiles/testprogram.dir/testPart.cpp.o
    [100%] Linking CXX executable ../../bin/testprogram
    [100%] Built target testprogram
    Scanning dependencies of target python_instrumentation
    [100%] Generating python_instrumentation_install
    running install
    running bdist_egg
    running egg_info
    writing /home/bareya/git/palanteer/python/palanteer.egg-info/PKG-INFO
    writing dependency_links to /home/bareya/git/palanteer/python/palanteer.egg-info/dependency_links.txt
    writing top-level names to /home/bareya/git/palanteer/python/palanteer.egg-info/top_level.txt
    reading manifest file '/home/bareya/git/palanteer/python/palanteer.egg-info/SOURCES.txt'
    writing manifest file '/home/bareya/git/palanteer/python/palanteer.egg-info/SOURCES.txt'
    installing library code to build/bdist.linux-x86_64/egg
    running install_lib
    running build_py
    running build_ext
    creating build/bdist.linux-x86_64/egg
    error: could not create 'build/bdist.linux-x86_64/egg': Permission denied
    make[2]: *** [python/CMakeFiles/python_instrumentation.dir/build.make:84: python/python_instrumentation_install] Error 1
    make[1]: *** [CMakeFiles/Makefile2:230: python/CMakeFiles/python_instrumentation.dir/all] Error 2
    make: *** [Makefile:103: all] Error 2
    
    bug scripting 
    opened by bareya 2
  • BUG: unable to use the timing view on different threads, always defaults to thread 0

    BUG: unable to use the timing view on different threads, always defaults to thread 0

    Hi, love the tool, however when instrumenting python and opening it in the viewer, pressing Profile timings always defaults to thread 0, I tracked down the code and patched it, can't say it's the best solution, but it worked for me:

    Index: server/viewer/vwMainProfile.cpp
    IDEA additional info:
    Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
    <+>UTF-8
    ===================================================================
    diff --git a/server/viewer/vwMainProfile.cpp b/server/viewer/vwMainProfile.cpp
    --- a/server/viewer/vwMainProfile.cpp	(revision 331398fe9c994bd921753e8d9ac9818b2e962326)
    +++ b/server/viewer/vwMainProfile.cpp	(date 1639396331682)
    @@ -71,7 +71,7 @@
         plgVar(PROF, threadUniqueHash, startTimeNs, getNiceDuration(timeRangeNs));
     
         // Add the request
    -    _profiles.push_back({id, kind, startTimeNs, timeRangeNs, threadUniqueHash});
    +    _profiles.push_back({id, kind, startTimeNs, timeRangeNs, threadUniqueHash,threadId});
         setFullScreenView(-1);
         return true;
     }
    @@ -130,12 +130,12 @@
         if(prof.computationLevel==0 && _backgroundComputationInUse) return true; // Waiting for a free slot
     
         // Finish the initialization if needed (init and live)
    -    if(prof.threadId<0 && (prof.isFirstRun || _liveRecordUpdated)) {
    +    if(prof.threadId!=3324 && (prof.isFirstRun || _liveRecordUpdated)) {
             prof.isFirstRun = false;
     
             for(int threadId=0; threadId<_record->threads.size(); ++threadId) {
                 if(_record->threads[threadId].threadUniqueHash!=prof.threadUniqueHash) continue;
    -            prof.threadId = threadId;
    +//            prof.threadId = threadId;
     
                 // Thread found: complete the profile initialization
                 if(prof.reqNestingLevel<0) {
    @@ -223,7 +223,7 @@
             u32 scopeLIdx2 = itScope.getNextScope(isCoarseScope, dummyScopeStartTimeNs, dummyScopeEndTimeNs, evt, durationNs);
             (void)scopeLIdx2;
             plAssert(!isCoarseScope);                                      // By design
    -        plAssert(scopeLIdx2==item.scopeLIdx, scopeLIdx2, item.scopeLIdx); // By design
    +//        plAssert(scopeLIdx2==item.scopeLIdx, scopeLIdx2, item.scopeLIdx); // By design
             prof.computationLevel = bsMinMax((int)(100LL*(evt.vS64-prof.startTimeNs)/prof.timeRangeNs), 1, 99); // 0 means just started, 100 means finished
     
             // Get infos on its children
    
    
    opened by jojado8408 1
  • Add option to run a python module as script

    Add option to run a python module as script

    Allow to run a python module directly from palanteer with a '-m'.

    python -m palanteer -m mymodule
    

    This is useful as not all modules can be invoked with their __init__.py or __main__.py (specially those with relative imports).

    opened by Victor333Huesca 1
  • plgScopeDyn() with USE_PL=0 throws build errors

    plgScopeDyn() with USE_PL=0 throws build errors

    Hello,

    Thank you for the Palanteer project. It has made my life a lot easier. Cheers to you guys!

    I face the following issue whenbuilding with Palanteer deactivated. I wish to deactivate Palanteer when my program is built in 'Release'. I noticed an issue I have with plgScopeDyn() when USE_PL is set to '0'.

    This is my code (USE_PL = 0):

    #define PL_IMPLEMENTATION 1
    #define PL_GROUP_TEST 1
    #include "palanteer.h"
    .
    .
    .
    [[maybe_unused]] auto text = "testFunc";
    plgScopeDyn(TEST, text);
    

    When I compile this code with clang, I get the following error: use of undeclared identifier 'TEST'

    The rest of the pl[g]***Dyn() variant functions (plgFunction(), plgLockScopeState(), do not seem to cause build errors.

    bug C++ instrumentation 
    opened by Lnsrini 1
  • Error: Assertion failed: lastScopeEndTimeNs<=scopeStartTimeNs in C++'s testprogram collect

    Error: Assertion failed: lastScopeEndTimeNs<=scopeStartTimeNs in C++'s testprogram collect

    First, thanks for your work on this tool :)

    I get an assertion failure on the viewer:

    build_main/bin/palanteer
    [PALANTEER] Assertion failed: lastScopeEndTimeNs<=scopeStartTimeNs
      On function: void vwMain::prepareTimeline(vwMain::Timeline&)
      On file    : ../server/viewer/vwMainTimeline.cpp(1407)
        - s64     lastScopeEndTimeNs   = 479190960
        - s64     scopeStartTimeNs     = 310591404
        - s64     scopeEndTimeNs       = 310948897
    

    when running

    build_main/bin/testprogram collect
    Mode 'connected'
    [00:00:00.023010505] [debug] [Not recorded] An integer value 1234
    [00:00:00.023035299] [info ] [Not recorded] Several other values 1234, -0.123, 3.14e+200 and 1234567891234567.
    [00:00:00.023054506] [warn ] [Not recorded] Some values 00001234 and some strings: 'rabbit
    and fox'.
    [00:00:00.023063934] [error] [Not recorded] A pointer 0x555ad6da99d7 with the address of the string
    Statistics:
      Execution time: 1118 ms
      Sending calls : 23
      Sent events   : 482235
      Sent strings  : 97
      Max dyn string usage: 37            ( 0.04% of max)
      Max buffer usage    : 3859520 bytes ( 5.51% of max)
    

    It happens both in v0.6 and in main. Commenting out the assert in vwMainTimeline.cpp allows me to use the tool, but...

    plAssert(lastScopeEndTimeNs<=scopeStartTimeNs, lastScopeEndTimeNs, scopeStartTimeNs, scopeEndTimeNs);
    

    Find attached the trace collected until the assert is triggered: Cpp testcollect.zip

    Some info about my system:

    Ubuntu 20.04
    g++ 9.3.0
    Python 3.8.10
    

    Thanks a lot for your time taking a look at this, really appreciate it.

    bug 
    opened by pamarcos 0
  • Error: unable to check the elem MR non increasing speck in Python's testprogram collect

    Error: unable to check the elem MR non increasing speck in Python's testprogram collect

    First of all, thanks a million for your work on this. I'm just playing around with Palanteer and I am getting the following error when trying to collect data with the Python example:

    python/testprogram/testprogram.py collect
    Mode 'connected'
    Statistics:
      Execution time: 1659 ms
    

    image

    I get it every single time this or any other app finishes. After that, I can't use the saved trace anymore. I can only work commenting out the check in cmRecord.cpp, even though I know this is not right, it's the only way I can use the tool:

    // for(int i=0; i<curArray.size(); ++i) {
    //     if(curArray[i].speckUs>upperArray[i/cmMRElemSize].speckUs) LOAD_ERROR("check the elem MR non increasing speck");
    // }
    

    Here's the file that is collected by the viewer, in case it's useful. When trying to open it with the viewer, I get the already mentioned error Python testcollect.zip

    This happens both in v0.6 and in main. It happens on every single Python application I've tested once it finishes. In case it's useful, some info about my system:

    Ubuntu 20.04
    g++ 9.3.0
    Python 3.8.10
    

    Again, thanks a lot for this tool and for your time taking a look at this issue.

    bug question 
    opened by pamarcos 4
  • Question - Shared libraries

    Question - Shared libraries

    Has the library a design for working in separated projects but they can be connected with one static library? I mean is it possible to create one class with implementation where it is a wrapper for palanteer. Otherwise, I can't understand why the header file doesn't include code even if I declare preprocessor PL_IMPLEMENTATION clearly in .cpp file.

    Or the purpose of this library is to test small codebases because I can't imagine how to use it if you have many separated projects that are connected with one main static library.

    As the result, I have the error LNK2019: unresolved external symbol. Describe the correct usage of your header in the case when I want to use the implementation in .cpp file, but have declarations of functions (USE_PL) in a header file and share it between all projects. It's really sad if I can't do that at all.

    opened by wh1t3lord 11
  • Hard to interpret fiber work when looking at list of threads

    Hard to interpret fiber work when looking at list of threads

    Since you previously mentioned workflow and usability wrt fibers, I figured I'd make this post, although I appreciate it's likely a bit more ambitious.

    There are a few issues I see in this area.

    The way I use FTL is to have every bit of work be performed by fibers - to the point that my 'main' thread of execution is just another fiber pinned to a specific worker. I have lot of fibers and use them for everything.

    When I look at this view, it doesn't really tell me what's going on, and I can't gleam much from it wrt what work is executing when/where. Highlighting a fiber span does highlight the corresponding function stack in the latter parts of the window, but this is difficult to see. image

    In FTL, the default number of fibers is 400, which, as you can imagine, blows up the size of the "Fibers" area quite a bit (and possibly hits an error message wrt thread limits from memory - can't check right now), and makes the aforementioned highlighting not really useful - which of the 400 fibers is being highlighted? No idea!

    Ideally, there would be a thread-first view of the worker threads that shows the work being performed on them as normal; i.e. how you would see work displayed on threads without using fibers - I think it matters less which fiber # is active when, and instead more which callstack is active when on which thread. So in this example on the left wouldn't be fibers but instead the worker threads executing any and all fibers, showing the work those threads are performing, with Palanteer doing the magic of tying fiber-based work to the threads that execute it.

    image

    Hopefully that makes sense. Again, totally appreciate it's a bunch of work. Just wanted to provide my perspective; happy to test any ideas in this area, incremental changes, prototypes, etc.

    viewer 
    opened by BrodyHiggerson 1
  • [Proof of Concept] MacOS Platform Layer

    [Proof of Concept] MacOS Platform Layer

    This is a rough pass at a MacOS platform layer for the Palanteer viewer application (note that I have not touched the instrumentation or scripting layer yet, and I haven't tested the networked recording, just loading trace files).

    @dfeneyrou Huge props for making a really great profiling tool and writing it in such a way that porting to a new platform is feasible in a tractable amount of time. Please let me know if having a MacOS platform layer in the codebase is something you'd be interested in. I don't mind either way; this is mostly a learning project for me.

    This is not really in a mergeable state yet, but I wanted to open it up for feedback and discussion on the approach. I've never written a shippable platform layer before and don't have a lot of experience with native MacOS APIs.

    From a usability perspective, the two biggest outstanding problems are

    • [ ] https://github.com/dfeneyrou/palanteer/issues/19
    • [ ] https://github.com/dfeneyrou/palanteer/issues/18

    Also:

    • [ ] the MacOS menus are not interactive while the main window has focus. I have no idea why yet.
    • [ ] the cmake changes are not well considered. I don't really know how to use cmake and would love suggestions on how to structure them better.
    • [ ] this still uses OpenGL, which is deprecated on MacOS. A Metal rendering backend would be faster and more likely to stay usable into the future, but I wouldn't know where to start since the existing platform layer is OpenGL only and doesn't have any hooks for other APIs like Vulkan or DirectX.
    opened by jceipek 0
  • [Mac OS port] Potential issues with keyboard modifier state

    [Mac OS port] Potential issues with keyboard modifier state

    In my MacOS port, I've been noticing issues where the application didn't realize I was holding down certain modifier keys. I believe the cause is that the modifier state isn't being appropriately synchronized here: https://github.com/dfeneyrou/palanteer/blob/main/server/viewer/vwPlatform.cpp#L642-L718

    Note that the kms parameter is ignored in many of the functions in the file, which can lead to these imgui fields not being synchronized to the keyboard state correctly:

    io.KeyCtrl
    io.KeyShift
    io.KeyAlt  
    io.KeySuper
    

    I also haven't been able to determine which osHandler->event* function would be best to call when responding to the NSEventTypeFlagsChanged event type on macOS. See https://github.com/ocornut/imgui/blob/0b8a2470743f89d19ab2d5920606434b604b529e/backends/imgui_impl_osx.mm#L342-L345 for how it is handled in the Dear ImGui example.

    experiment 
    opened by jceipek 2
Releases(v0.6)
  • v0.6(Dec 30, 2021)

    This is a feature delivery release

    Compared to the previous release, the main added changes are:

    • Feature (global): efficient printf-like logging (supersedes markers).
      • nanosecond logging performance
      • format arguments can be searched and graphed
    • Feature in the viewer: some exports have been added
    • Important fix: instrumentation crash under stress
    • Important fix: correctness of multi-resolution graphs

    Behavior change / compatibility break

    • Viewer: the marker window has been replaced with the log window, which generalizes markers and provides more features
    • Viewer: old stored records will not be readable anymore (incompatibility due to somes changes for the logs)
    • Instrumentation: old viewers are not compatible, due to transport header change.
    • Instrumentation: plMarker APIs are deprecated.
      • they are currently wrapped on plLogWarn function and will be removed soon

    New features

    • Global: efficient printf-like logging
      • nanosecond logging performance
      • format arguments can be searched and graphed
      • a comparison with Nanolog and spdlog is provided
    • Viewer: some exports available
      • anywhere with ctrl-P for screen capture
      • in main menu bar for Chrome Trace Format (JSON)
      • in text and log windows for a text export
      • in plot windows for CSV export

    Fixes and improvements

    • C++ instru: remove a critical flaw in the event collection mechanism which could lead to a crash under stress (thanks @gpascualg for the report with details)
    • Python instru: the filename of the exception source is now provided in the log text, along with the line number
    • Viewer: reworked the computation of the multi-resolution of the graphs. Previous version was broken and provided poor visual results
    • Viewer: fix the profiling applied always on a particular thread, for threads without provided names (thanks @jojado8408 for reporting)
    • Code cleaning: fix "issues" highlighted by the tool include-what-you-use
    • Code cleaning: fix "issues" highlighted by the static analysis tool CodeChecker
    • Code cleaning: remove warnings when compiling under Windows with the flag /W4 /permissive- (thanks @gpascualg and @BrodyHiggerson)
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.6.0.Python.instrumentation.wheels.zip(321.70 KB)
    Palanteer.v0.6.0.scripting.wheels.zip(1.54 MB)
    Palanteer.v0.6.0.Windows.binaries.zip(1.01 MB)
  • v0.5(Nov 21, 2021)

    This is a feature delivery release

    Compared to the previous release, the main added features are:

    • Multi-stream (or multi-process) recording
    • Automatic C++ instrumentation (GCC only)

    Behavior change / compatibility break

    • Viewer: external string lookups are now per record (they were previously per application).
    • Viewer: old stored records will not be readable anymore (incompatibility due to the added stream informations)
    • Instrumentation: old viewers are not compatible, due to transport header change.

    New features

    • Server and Viewer: add support for multistream (or multiprocess) records
      • Server: support for multiple socket connections and multistream recording
      • Viewer: add the configuration menu for the mono/multi stream
      • Viewer: file dialog supports multi selection with highlight
      • Viewer: record options are displayed per stream
    • Viewer: enable Dear ImGui keyboard navigation
    • Instrumentation: support of automatic C++ function instrumentation (GCC only) The external string lookup is now independent for each record, and covers also this feature.
    • Python: add support for Python 3.10 packages

    Fixes and improvements

    • Viewer: lock use can now be graphed for all threads (menu on the lock name)
    • Viewer: in Text view, all events with dates are now taken into account for navigation
    • Viewer: fix a crash when asking an histogram for a "lock use" scope
    • Viewer: fix persistence of graphs between launches
    • Viewer: fix a crash when the saved layout is not matching the record thread names
    • Viewer: fix the display of the used size of records (now 64 bits size)
    • Server: more robust handling of duplicated thread names
    • Server: fix a crash when getting memory details with big quantity of non released allocations
    • Python: fix an incorrect event logging sequence when both using coroutines and tracing C calls
    • Python instru: disable an annoying warning on Windows
    • C++ instru: collect the used language, the context switch collection state and the auto instrumentation state
    • C++ instru: waiting for server connection is now a configurable timeout, no more a binary state
    • C++ instru & server: more robust short date handling
    • C++ instru: more robust initialization
    • C++ instru: threads (standard or virtual) can be declared before service initialization and are persistent across multiple service initialization (thanks @BrodyHiggerson for the use case)
    • C++ instru: reduced disabled Palanteer include cost on windows with USE_PL=0 (now a few millisecond, as for Linux)
    • Scripting: improve support of external strings, now applied also on the event specification
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.5.0.Python.instrumentation.wheels.zip(321.20 KB)
    Palanteer.v0.5.0.scripting.wheels.zip(1.93 MB)
    Palanteer.v0.5.0.Windows.binaries.zip(997.06 KB)
  • v0.4(Sep 9, 2021)

    This is a bug fix release

    Behavior change / compatibility break

    • None

    New features

    • Viewer: add support for high DPI

    Fixes and improvements

    • Python instrumentation: fix a crash when tracing C calls
    • Viewer: fix a crash in some cases in the file dialog window when playing with sorting
    • C++ instrumentation: added printf-like API for plDeclareVirtualThread and plDeclareThreadDyn
    • Documentation updated
    • Documentation: upgraded Markdeep
    • Viewer: upgraded Dear ImGui
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.4.0.Python.instrumentation.wheels.zip(267.65 KB)
    Palanteer.v0.4.0.scripting.wheels.zip(1.55 MB)
    Palanteer.v0.4.0.Windows.binaries.zip(980.55 KB)
  • v0.3(Aug 16, 2021)

    This is a general maintenance release

    Compared to the previous release, the main changes are:

    • Addition of the 'compact application model' taking advantage of 32 bits architectures to reduce the exchanged data to 12 bytes per event (instead of 24 bytes)
    • 10% speed gain on server side (compression library update)

    Behavior change / compatibility break

    • Viewer: old stored records will not be readable anymore (break in 6a1bcdf13e79f1ffa666682e502b444bcf739f20)
    • Instrumentation: old viewers are not compatible, due to added options (see below). But the current viewer accept older instrumentation libraries.

    New features

    • Instrumentation: add support for a hash 'salt', useful when using 32 bits hash to remove potential collisions.
    • Instrumentation: add support for the 'compact model', allowing 50% reduction of used bandwidth (i.e. 12 bytes per event) between client and server, under some instrumentation constraints
    • Python: add interface to profile Python modules (thanks @Victor333Huesca!)
    • Scripting improved API to handle the case of externally launched programs (thanks @LotemAm!)
    • Viewer: application icon added under Windows

    Fixes and improvements

    • Viewer: display of all instrumentation options in the 'Record view'
    • Instrumentation: Added the missing "group" version of plDeclareThread
    • Server: add the missing control of the instrumentation protocol version, to detect client-server incompatibilities
    • Documentation updated
    • Viewer: application icon added under Windows
    • Server: upgraded compression library zstd to benefit from the recent speed improvement for low compression ratios.
    • Viewer: upgraded Dear ImGui and stb_image.h
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.3.0.Python.instrumentation.wheels.zip(266.39 KB)
    Palanteer.v0.3.0.scripting.wheels.zip(1.55 MB)
    Palanteer.v0.3.0.Windows.binaries.zip(979.04 KB)
  • v0.2(Jul 31, 2021)

    This is the first Palanteer official release

    Compared to the initial commit, the main changes are:

    • Virtual/userland thread support
    • Stability fixes (one of them critical)
    • Improved packaging.

    Behavior change / compatibility break

    • Viewer: old stored records will not be readable anymore (break in 8e9e9ac721692222f516fcff0346925f1597f30c)
    • The Python instrumentation does not log anymore the C calls by default. Indeed, wildly used built-in function (like list "append") may be very heavy and are not always necessary

    New features

    • Viewer: record catalog improvement: total size per app is displayed and a menu to collapse/open alls app was added
    • Server: 10% faster event processing on server side by disabling specific assertions in containers in release mode.
    • Virtual/green/userland thread support in C++, and the equivalent asyncio/gevent/greenlet in Python
    • Improved CMakeFile.txt (thanks @bareya, @RichieSams!)
    • Python packages are now wheels
    • Python code is now formatted for PEP8 (with the tool "black")

    Fixes

    • Server: fixed the lock event automata (a not taken lock event after a wait begin event was not ended as it should)
    • Viewer: fixed the search on Windows (strcasestr exists but does not work properly)
    • Viewer: fixed the behavior of clicking on items in the text view
    • Viewer: fixed the plot and histogram layout persistency
    • Server: filter problematic characters for a file in the sent application name
    • Server: improve robustness and behavior of the server connection automata
    • Server: improve robustness of the server against corrupted data sent from instrumentation
    • Instrumentation; fixed a major stability issue (event corruption) in the collection mechanism
    • Viewer: fixed proper quitting of the viewer
    • Instrumentation: fixed missing deactivated APIs (thanks @Lnsrini, @learn-more)
    • Tools: fixed missing API names in the tool extStringCppParser.py
    • Documentation improvement (thanks @ajweeks!)
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.2.0.Python.instrumentation.wheels.zip(264.85 KB)
    Palanteer.v0.2.0.scripting.wheels.zip(1.47 MB)
    Palanteer.v0.2.0.Windows.binaries.zip(944.92 KB)
Owner
Damien Feneyrou
Damien Feneyrou
HyperDbg debugger is an open-source, hypervisor-assisted user-mode, and kernel-mode Windows debugger 🐞

HyperDbg debugger is an open-source, hypervisor-assisted user-mode, and kernel-mode Windows debugger with a focus on using modern hardware technologies. It is a debugger designed for analyzing, fuzzing and reversing. ??

HyperDbg 1.7k Jul 28, 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 Jul 23, 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.3k Jul 29, 2022
A modern, C++-native, header-only, test framework for unit-tests, TDD and BDD - using C++11, C++14, C++17 and later (or C++03 on the Catch1.x branch)

Catch2 v3 is being developed! You are on the devel branch, where the next major version, v3, of Catch2 is being developed. As it is a significant rewo

Catch Org 15.4k Aug 1, 2022
A modern, C++-native, header-only, test framework for unit-tests, TDD and BDD - using C++11, C++14, C++17 and later (or C++03 on the Catch1.x branch)

Catch2 v3 is being developed! You are on the devel branch, where the next major version, v3, of Catch2 is being developed. As it is a significant rewo

Catch Org 15.3k Jul 26, 2022
Write tests in C

NAME libtap - Write tests in C SYNOPSIS #include <tap.h> int main () { plan(5); int bronze = 1, silver = 2, gold = 3; ok(bronze < silver,

Jacob Gelbman 222 Jun 10, 2022
Execute Input/Output tests on a software

IO-Tester The goal of this software is to take files as parameter that contains lists of inputs and expected ouputs and to tell the user if the tests

Martin 32 Jul 18, 2022
The world's first free and open-source PlayStation 3 emulator/debugger, written in C++ for Windows and Linux.

The world's first free and open-source PlayStation 3 emulator/debugger, written in C++ for Windows and Linux.

null 11.5k Aug 4, 2022
With xshellex you can paste any kind of c-shellcode strings in x64dbg, ollydbg & immunity debugger

With xshellex you can paste any kind of c-shellcode strings in x64dbg, ollydbg & immunity debugger. Also you can convert the "binary-copied-clipboard" to c-shellcode string.

David Reguera Garcia aka Dreg 29 Jul 27, 2022
A Garry's Mod module that creates a Remote DeBugger server

gm_rdb A Garry's Mod module that creates a Remote DeBugger server. Provides Lua debugging (using LRDB) and access to the Source engine console. Compil

Daniel 14 Jul 7, 2022
heaptrace is a ptrace-based debugger for tracking glibc heap operations in ELF64 (x86_64) binaries

heaptrace is a ptrace-based debugger for tracking glibc heap operations in ELF64 (x86_64) binaries. Its purpose is to help visualize heap operations when debugging binaries or doing heap pwn.

Aaron Esau 236 Jul 27, 2022
A small, educational debugger with no dependencies

smldbg A small, educational debugger with no dependencies. Prerequisites To build the project and run the tests, the following are required: A C++20 c

null 3 Jun 16, 2022
Fft-benchmark - A benchmark for comparison of FFT algorithms performance

FFT benchmark A benchmark for comparison of FFT algorithms performance. Currently supports Intel IPP, KFR, FFTW and KissFFT. Requires: Clang 6.0+ (GCC

KFR 16 Apr 7, 2022
DotX64Dbg aims to provide a seamless way to write and test plugins for X64Dbg using .Net 5.0 and C#.

DotX64Dbg (EARLY ALPHA) Plugins and Scripting with C# for x64Dbg. Create Plugins for X64Dbg with ease DotX64Dbg aims to provide a seamless way to writ

ζeh Matt 7 Jan 21, 2022
CppUTest unit testing and mocking framework for C/C++

CppUTest CppUTest unit testing and mocking framework for C/C++ More information on the project page Slack channel: Join if link not expired Getting St

CppUTest 1.1k Jul 27, 2022
Googletest - Google Testing and Mocking Framework

GoogleTest OSS Builds Status Announcements Release 1.10.x Release 1.10.x is now available. Coming Soon Post 1.10.x googletest will follow Abseil Live

Google 27.1k Jul 31, 2022
A simple C++ 03/11/etc timer class for ~microsecond-precision cross-platform benchmarking. The implementation is as limited and as simple as possible to create the lowest amount of overhead.

plf_nanotimer A simple C++ 03/11/etc timer class for ~microsecond-precision cross-platform benchmarking. The implementation is as limited and simple a

Matt Bentley 89 Jul 15, 2022
🧪 single header unit testing framework for C and C++

?? utest.h A simple one header solution to unit testing for C/C++. Usage Just #include "utest.h" in your code! The current supported platforms are Lin

Neil Henning 499 Aug 5, 2022
Anti-Debug and Anti-Memory Dump for Android

AntiDebugandMemoryDump Anti-Debug and Anti-Memory Dump for Android Some known techniques for anti-debug and anti-memory dump have been used in this pr

Darvin 165 Aug 5, 2022