Visual Leak Detector for Visual C++ 2008-2015

Overview

Visual Leak Detector Build status PayPal donate button

Introduction

Visual C++ provides built-in memory leak detection, but its capabilities are minimal at best. This memory leak detector was created as a free alternative to the built-in memory leak detector provided with Visual C++. Here are some of Visual Leak Detector's features, none of which exist in the built-in detector:

  • Provides a complete stack trace for each leaked block, including source file and line number information when available.
  • Detects most, if not all, types of in-process memory leaks including COM-based leaks, and pure Win32 heap-based leaks.
  • Selected modules (DLLs or even the main EXE) can be excluded from leak detection.
  • Provides complete data dumps (in hex and ASCII) of leaked blocks.
  • Customizable memory leak report: can be saved to a file or sent to the debugger and can include a variable level of detail.

Other after-market leak detectors for Visual C++ are already available. But most of the really popular ones, like Purify and BoundsChecker, are very expensive. A few free alternatives exist, but they're often too intrusive, restrictive, or unreliable. Visual Leak Detector is currently the only freely available memory leak detector for Visual C++ that provides all of the above professional-level features packaged neatly in an easy-to-use library.

Visual Leak Detector is licensed free of charge as a service to the Windows developer community. If you find it to be useful and would like to just say "Thanks!", or you think it stinks and would like to say "This thing sucks!", please feel free to drop us a note. Or, if you'd prefer, you can contribute a small donation. Both are very appreciated.

Documentation

Read the documentation at https://github.com/KindDragon/vld/wiki

Contributing

We encourage developers who've added their own features, or fixed bugs they've found, to contribute to the project. The full version-controlled source tree is available publicly via Git at the URL below. Feel free to clone from this URL and submit patches for consideration for inclusion in future versions. You can also issue pull requests for changes that you've made and would like to share.

Copyright © 2005-2017 VLD Team

Comments
  • Work performed on various issues

    Work performed on various issues

    The highlights of the changes made are as follows:

    • Install a hook on LdrpCallInitRoutine() or the relevant nt loader code to cover all Windows XP to Windows 10, x86 and x64 platforms in order to Refresh Modules before the dll entry point. The current implementation Refreshes the Modules after the dll entry point which in effect does not detect any allocations made on dll entry point.
    • Fix #9519, #9859, #10544, use LoaderLock to serialize any calls which load additional libraries or require access to the Loader Lock.
    • Fix #6359, #10553, fix crashes and failure to register COM dlls where Visual Leak Detector is unloaded before IMalloc interface is released.
    • Optimize _GetProcAddress and _GetProcAddressForCaller to properly test for ordinal vs function name
    • Append Visual Studio 2015/2013/2012/2010/2008 symbols cache directory where multiple VS versions are installed on the same system.
    • Add option to skip reporting crt startup allocations as memory leaks
      • for debug runtime (where debug crt allocations are not properly identied) and
      • for release runtime (by excluding certain startup crt initialisation modules), ~~this may have an effect in performance.~~
    • Improve the vld.ini searching from additional locations listed below in order, and fix installer issue where it would not set the vld.ini path in registry for x64 platform:
      • current directory
      • directory where VLDDLL resides
      • directory where executable resides
      • path specified in registry HKCU
      • path specified in registry HKLM
    • All other commits resolve compiler warnings and improvements to the code following PVS-Studio analysis.
    • Clean up of solutions and project files
    • Improvements and additions to test cases

    I tried to keep commits independed of each other as much as possible, to make review easier.

    I would suggest to cherypick as much as possible into master in order to rebase this PR and leave us with only the commits that need discussion.

    opened by ioannis-e 61
  • Use CaptureContext class to simplify code in hooks

    Use CaptureContext class to simplify code in hooks

    Document special case in vld_unload test Enable capturing vector_new... in msvcrtPatch Skip stack trace for frames internal to vld Use CaptureContext class to simplify code in hooks

    opened by ioannis-e 31
  • VLD Crashes

    VLD Crashes

    I'm getting crashes every few times running vld 2.5 (although I also get crashes with vld 2.3 and 2.4). If needed I can later give more exhaustive information about my configuration, but I have a primary issue to bring up first. When my application starts vld reports several "New allocation at already allocated address" messages. When it crashes, it crashes on the getCrtBlockUse call in reportLeaks.

    Based on the comment in mapBlock:

    //block with this address has already been allocated. The // previously allocated block must have been freed (probably by some // mechanism unknown to VLD), or the heap wouldn't have allocated it // again. Replace the previously allocated info with the new info.

    I had the following thought.

    If this "unknown mechanism" is unallocating memory, then if it unallocates it and never reallocates it, the block map will stale and the contained block will no longer be valid. Then when that block is accessed you will get a crash.

    I may be wrong, but my current guess is that this is the cause of my crashes. Any ideas how it could be fixed?

    I'm using Visual Studio 2013, Win10, 64-bit.

    opened by rconde01 9
  • rebased ioannise PR

    rebased ioannise PR

    https://vld.codeplex.com/SourceControl/network/forks/ioannise/vld/contribution/8453 rebased it to current master to fix https://vld.codeplex.com/workitem/9519

    Otherwise it's impossible to use vld with Qt or any other framework using file open dialogs. Tested with VS2015 x64 on Windows 7.

    opened by Trass3r 7
  • How do I uninstall this thing?

    How do I uninstall this thing?

    Uninstalled Visual Leak detector, but still when creating Win32 C++ projects I always get "C:\Program Files (x86)\Visual Leak Detector\include" item in Additional Include Directories in project properties. Same for "C:\Program Files (x86)\Visual Leak Detector\lib\Win32" in Additional Library Directories. These settings are set by default for all Visual Studio 2013 C++ projects.

    How do I get rid of these default settings? Thanks

    opened by decare 4
  • Installation of vld-2.5-setup.exe on 32-bit WinXP fails

    Installation of vld-2.5-setup.exe on 32-bit WinXP fails

    The v2.5 installer fails on 32-bit WinXP SP3 with an Internal error: Cannot access 64-bit registry keys on this version of Windows.. The v2.4rc2 installer runs without errors.

    opened by tbeu 4
  • Fix Release_StaticCrt tests

    Fix Release_StaticCrt tests

    Previous work on PR #8

    Doesn't work v90-v110 Release_StaticCrt tests

    Current build results https://ci.appveyor.com/project/KindDragon/vld/build/134

    /cc @ioannis-e

    opened by KindDragon 2
  • VS2008 only output

    VS2008 only output "New allocation at already allocated address:"

    Hello, everyone:

    I use VLD in several projects under Visual Studio 2008(64bit). I have integrated it to my new project but it seems doesn't work at all.

    I run the project in debug mode.

    The output window only has:

    VLD: New allocation at already allocated address: 0x0000000001E7CA00 with size: 576 and new size: 564
    

    I can not see this message in other projects.

    I also modify the vld.ini file and set [ReportTo] to both.

    But the output file is empty.

    Any help will be appreciated.

    opened by xiaoliuzi 1
  • Not showing file name and line number in leak dump

    Not showing file name and line number in leak dump

    I've been having this issue where VLD doesn't tell me file names and line numbers in the call stack. main.cpp:

    #include <iostream>
    
    #include <vld.h>
    /*#define _CRTDBG_MAP_ALLOC
    #include <stdlib.h>
    #include <crtdbg.h>*/
    
    #include "engine.h"
    #include "levelmanager.h"
    #include "opengl.h"
    
    int main(int argc, char *argv[]) {
    	if (!Engine::init(&argc, argv))
    		return 1;
    
    	int *i = new int();
    
    	//Engine::getLevelManager()->load("Level1");
    
    	glutMainLoop();
    
    	Engine::shutdown();
    	//_CrtDumpMemoryLeaks();
    
    	return 0;
    }
    

    Output:

    ---------- Block 5 at 0x065FD190: 4 bytes ----------
      Leak Hash: 0x2CDE864B, Count: 1, Total 4 bytes
      Call Stack (TID 13128):
        ucrtbased.dll!malloc()
        GameProject.exe!0x00398C1D()
        GameProject.exe!0x0033B2D2()
        GameProject.exe!0x0039A43E()
        GameProject.exe!0x0039A2E0()
        GameProject.exe!0x0039A17D()
        GameProject.exe!0x0039A4B8()
        KERNEL32.DLL!BaseThreadInitThunk() + 0x24 bytes
        ntdll.dll!RtlGetAppContainerNamedObjectPath() + 0x137 bytes
        ntdll.dll!RtlGetAppContainerNamedObjectPath() + 0x107 bytes
      Data:
        00 00 00 00                                                  ........ ........
    

    The main.cpp has a new int() which is never deleted, and since it's right in the main.cpp, it shouldn't be going through external dlls or some-such, and all of the memory leaks I can see show up like above.

    opened by Saftur 1
  • Binaries for Windows after CodePlex is going read-only

    Binaries for Windows after CodePlex is going read-only

    Since CodePlex is going read-only the binaries hosted over here surely won't get updated I assume? I wanted to know whether you are going to host those binaries here on GitHub as well.

    opened by ghost 1
  • dynamic_app test StackWalkMethod=safe Release sometimes crash

    dynamic_app test StackWalkMethod=safe Release sometimes crash

    Test DynamicLoader.MultithreadLoadingTests :cry:

        ntdll.dll!RtlpFreeHeap()    Unknown
        [email protected]()    Unknown
    >   vld_x86.dll!VisualLeakDetector::_RtlFreeHeap(void * heap, unsigned long flags, void * mem) Line 237 C++
        msvcrt.dll!_free() Unknown
        dbghelp.dll!operator delete[](void *)   Unknown
        dbghelp.dll!NMT::~NMT(void) Unknown
        dbghelp.dll!NMP::`scalar deleting destructor'(unsigned int) Unknown
        dbghelp.dll!NMP::close(void)    Unknown
        dbghelp.dll!CDiaSession::~CDiaSession(void) Unknown
        dbghelp.dll!CDiaSession::`scalar deleting destructor'(unsigned int) Unknown
        dbghelp.dll!ObjSymBase::Release(void)   Unknown
        dbghelp.dll!CDiaSymbol::Release(void)   Unknown
        dbghelp.dll!CDiaFrameData::~CDiaFrameData(void) Unknown
        dbghelp.dll!CDiaFrameData::`scalar deleting destructor'(unsigned int)   Unknown
        dbghelp.dll!ObjSymBase::Release(void)   Unknown
        dbghelp.dll!CDiaSymbol::Release(void)   Unknown
        dbghelp.dll!DbhStackServices::FreeUnwindInfoFromSymbols(void *,unsigned long)   Unknown
        dbghelp.dll!DbsStackServices::UnwindInfoHolder::~UnwindInfoHolder(void) Unknown
        dbghelp.dll!DbsX86StackUnwinder::ApplyUnwindInfo(void)  Unknown
        dbghelp.dll!DbsX86StackUnwinder::Unwind(void)   Unknown
        dbghelp.dll!DbsStackUnwinder::DbhUnwind(struct _tagSTACKFRAME64 *,unsigned long,void *,unsigned long,void *)    Unknown
        dbghelp.dll!PickX86Walk(class DbsStackUnwinder *,class DbhStackServices *,struct _tagSTACKFRAME64 *,void *) Unknown
        [email protected]()  Unknown
        vld_x86.dll!SafeCallStack::getStackTrace(unsigned int maxdepth, const context_t & context) Line 797 C++
        vld_x86.dll!CaptureContext::~CaptureContext() Line 2902 C++
        vld_x86.dll!CrtPatch<140,0>::crtd_malloc(unsigned int size) Line 461    C++
        dynamic.dll!allocator<0>::alloc(LeakOption type, bool) Line 82  C++
        dynamic.dll!SimpleLeak_Malloc() Line 17 C++
        dynamic_app.exe!RunLoaderTests(bool resolve) Line 55    C++
        dynamic_app.exe!Dynamic_Thread_Procedure(void * foo) Line 60    C++
        ucrtbase.dll!__crt_at_quick_exit() Unknown
        [email protected]@12() Unknown
        ntdll.dll!__RtlUserThreadStart()    Unknown
        [email protected]() Unknown
    

    Unhandled exception at 0x77BC1797 (ntdll.dll) in dynamic_app.exe: 0xC0000005: Access violation reading location 0x00000000.

    v140

    /cc @ioannis-e @akaStiX

    opened by KindDragon 1
  • Leaks reported in STL containers like vectors, map

    Leaks reported in STL containers like vectors, map

    When using VLD with my existing codebase and Microsoft CPP test framework I am getting leaks in xmemory, xtree which are used in vector and map. As these are expected to get deleted when they get out of scope.

    I guess this could be because VLD exits before vectors and maps go out of scope.

    opened by sparkskapil 0
  • VLD 2.5.1 report false positive on Visual Studio 2017, MFC, Window 10

    VLD 2.5.1 report false positive on Visual Studio 2017, MFC, Window 10

    We have a possible false positive detection of memory leaks on window 10, vs 2017, MFC:

    ---------- Block 186011 at 0x0000000070C00B50: 512 bytes ---------- Leak Hash: 0x14098C6C, Count: 1, Total 512 bytes Call Stack (TID 177604): ucrtbased.dll!malloc_dbg() mfc140d.dll!0x00007FFF47920001() mfc140d.dll!0x00007FFF478A0A4B() mfc140d.dll!0x00007FFF47707DAB() e:\addoc iim\apuisoft dev\customer.cpp (1801): Addoc64D.exe!CCustomerApp::OnIdle() + 0xE bytes mfc140d.dll!0x00007FFF478A0F02() mfc140d.dll!0x00007FFF47708E13() mfc140d.dll!0x00007FFF47920C44() d:\agent_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\appmodul.cpp (26): Addoc64D.exe!WinMain() d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (107): Addoc64D.exe!invoke_main() d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288): Addoc64D.exe!__scrt_common_main_seh() + 0x5 bytes d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (331): Addoc64D.exe!__scrt_common_main() d:\agent_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_winmain.cpp (17): Addoc64D.exe!WinMainCRTStartup() KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes ntdll.dll!RtlUserThreadStart() + 0x21 bytes Data: CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........ CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ........ ........

    Visual Leak Detector detected 6 memory leaks (1704 bytes). Largest number used: 7719945 bytes. Total allocations: 1502986993 bytes. Visual Leak Detector is now exiting. Detected memory leaks!

    Do you know how to skip/filter such log in the report ? Thank

    opened by kvcuong 2
  • Multiply defined symbols

    Multiply defined symbols

    I am getting linker errors complaining about symbols such as __VLD_maxtraceframes already defined. This is a showstopper. Please give correct instructions about where to include vld.h and how to avoid these errors.

    opened by CedricCicada 0
  • Documentation says #include vld.h must be after stdafx.h, but fatal error is thrown if I do

    Documentation says #include vld.h must be after stdafx.h, but fatal error is thrown if I do

    The vld.h file contains this:

    #ifdef __AFXWIN_H__ #error[VLD COMPILE ERROR] '#include <vld.h>' should appear before '#include <afxwin.h>' in file stdafx.h #endif

    But the documentation says this:

    "In at least one C/C++ source file from your program, include the vld.h header file. It should not matter which file you add the include statement to. It also should not matter in what order the header is included in relation to other headers. The only exception is stdafx.h (or any other precompiled header). A precompiled header, such as stdafx.h, must always be the first header included in a source file, so vld.h must be included after any precompiled headers."

    Please fix one or the other.

    opened by CedricCicada 3
Releases(v2.5.1)
  • v2.5.1(Oct 17, 2017)

    2.5.1

    Enhancements:

    • PDB added to installer.

    Bugs Fixed:

    • Fix ntdll loader patch for Windows 10 (1607) Anniversary Update causing crashes (thanks to @ioannis-e).
    • Vld dll loading order fixed with MFC.
    • Suppressible msgboxes in setup with cmdline /silent /suppressmsgboxes.

    2.5

    Enhancements:

    • VS2015 support added.
    • Windows 10 support added.
    • Support MFC 12 MBCS (thanks to @mnissl).
    • VLD config through env. vars (thanks to @akaStiX).
    • Support detection DllMain allocations (thanks to @ioannis-e).
    • Add option to skip reporting crt startup allocations as memory leaks (thanks to @ioannis-e).
    • Improve the vld.ini searching from additional locations (thanks to @ioannis-e).
    • Changed implementation of FastCallStack::getStackTrace for 32-bit code.

    Bugs Fixed:

    • Fix #9519, #9859, #10544, use LoaderLock to serialize any calls which load additional libraries or require access to the Loader Lock (thanks to @ioannis-e).
    • Fix #6359, #10553, fix crashes and failure to register COM dlls where Visual Leak Detector is unloaded before IMalloc interface is released (thanks to @ioannis-e).
    • Fix #10548, vld.ini search path (thanks to @ioannis-e).
    • Fix #10587, Visual Leak Detector reporting strange leaks in CRT module of VC++ (thanks to @ioannis-e).
    • Fix #10588, false positives from CRT in VS2013 with /MTd (thanks to @ioannis-e).
    • Deadlock fixed with StackWalkMethod=safe.

    Downloads

    Source code(tar.gz)
    Source code(zip)
    vld-2.5.1-setup.exe(2.81 MB)
  • v2.5(Jan 8, 2016)

    Enhancements:

    • VS2015 support added.
    • Windows 10 support added.
    • Support MFC 12 MBCS (thanks to @mnissl).
    • VLD config through env. vars (thanks to @akaStiX).
    • Support detection DllMain allocations (thanks to @ioannis-e).
    • Add option to skip reporting crt startup allocations as memory leaks (thanks to @ioannis-e).
    • Improve the vld.ini searching from additional locations (thanks to @ioannis-e).
    • Changed implementation of FastCallStack::getStackTrace for 32-bit code.

    Bugs Fixed:

    • Fix #9519, #9859, #10544, use LoaderLock to serialize any calls which load additional libraries or require access to the Loader Lock (thanks to @ioannis-e).
    • Fix #6359, #10553, fix crashes and failure to register COM dlls where Visual Leak Detector is unloaded before IMalloc interface is released (thanks to @ioannis-e).
    • Fix #10548, vld.ini search path (thanks to @ioannis-e).
    • Fix #10587, Visual Leak Detector reporting strange leaks in CRT module of VC++ (thanks to @ioannis-e).
    • Fix #10588, false positives from CRT in VS2013 with /MTd (thanks to @ioannis-e).
    • Deadlock fixed with StackWalkMethod=safe.
    Source code(tar.gz)
    Source code(zip)
Windows 7/2008 R2 EoP

Windows RpcEptMapper Service EoP exploit Clément Labro (@itm4n) released in November 12, 2020 all the details for a vulnerability on Windows 7 and Win

neosysforensics 13 Mar 29, 2021
Plan 9 History, from 1992-09-21 to 2015-01-10.

This is a re-release of the final version of the 4th Edition of Plan 9 from Bell Labs distributed directly by Bell Labs.

Plan 9 Foundation 329 Nov 23, 2022
Source Code and Embedded Design of Our Factory Robot at AUTCup 2015 Competitions

AUTCup 2015 @Factory Robot This repository contains the source code and embedded design of our @Factory robot at AUTCup 2015 competitions. The robot w

Meysam Parvizi 1 Oct 20, 2021
A demonstration PoC for CVE-2022-21877 (storage spaces controller memory leak)

POC CVE-2022-21877 This repository contains a POC for the CVE-2022-21877, found by Quang Linh, working at STAR Labs. This is an information leak found

null 4 Mar 8, 2022
RRxIO - Robust Radar Visual/Thermal Inertial Odometry: Robust and accurate state estimation even in challenging visual conditions.

RRxIO - Robust Radar Visual/Thermal Inertial Odometry RRxIO offers robust and accurate state estimation even in challenging visual conditions. RRxIO c

Christopher Doer 61 Nov 11, 2022
Tightly coupled GNSS-Visual-Inertial system for locally smooth and globally consistent state estimation in complex environment.

GVINS GVINS: Tightly Coupled GNSS-Visual-Inertial Fusion for Smooth and Consistent State Estimation. paper link Authors: Shaozu CAO, Xiuyuan LU and Sh

HKUST Aerial Robotics Group 572 Nov 27, 2022
LVI-SAM: Tightly-coupled Lidar-Visual-Inertial Odometry via Smoothing and Mapping

LVI-SAM This repository contains code for a lidar-visual-inertial odometry and mapping system, which combines the advantages of LIO-SAM and Vins-Mono

Tixiao Shan 1.1k Nov 25, 2022
Bungie's Oni modified so it compiles with Microsoft Visual Studio 2019.

OniFoxed What's this? This is a modified variant of the recently leaked Oni source code so that it compiles under Microsoft Visual Studio 2019 with so

Mark Sowden 58 Nov 28, 2022
VID-Fusion: Robust Visual-Inertial-Dynamics Odometry for Accurate External Force Estimation

VID-Fusion VID-Fusion: Robust Visual-Inertial-Dynamics Odometry for Accurate External Force Estimation Authors: Ziming Ding , Tiankai Yang, Kunyi Zhan

ZJU FAST Lab 86 Nov 18, 2022
A dataset containing synchronized visual, inertial and GNSS raw measurements.

GVINS-Dataset Author/Maintainer: CAO Shaozu (shaozu.cao AT gmail.com), LU Xiuyuan (xluaj AT connect.ust.hk) This repository hosts dataset collected du

HKUST Aerial Robotics Group 131 Nov 22, 2022
Continuous-Time Spline Visual-Inertial Odometry

Continuous-Time Spline Visual-Inertial Odometry Related Publications Direct Sparse Odometry, J. Engel, V. Koltun, D. Cremers, In IEEE Transactions on

Minnesota Interactive Robotics and Vision Laboratory 68 Nov 18, 2022
visual servo for mars rover

Mars_Rover visual servo for mars rover Start the simulation without mars environment roslaunch curiosity_mars_rover_description main_simple.launch Sta

Chenghao Wang 17 Jul 28, 2022
A D++ Discord Bot template for Visual Studio 2019 (x64 and x86)

D++ Windows Bot Template A D++ Discord Bot template for Visual Studio 2019 (x64 and x86, release and debug). The result of this tutorial. This templat

brainbox.cc 26 Nov 29, 2022
A Visual Studio template used to create Cobalt Strike BOFs

Introduction Cobalt Strike beacon object files (BOFs) is a feature that added to the beacon in order to allow rapid beacon extendibility in a more OPS

Securify 162 Nov 26, 2022
A visual, musical editor for delay effects

DelayArchitect A visual, musical editor for delay effects Download development builds 32-bit Windows VST3 64-bit Windows VST3 64-bit GNU/Linux VST3 ma

JP Cimalando 86 Nov 26, 2022
Visual-inertial-wheel fusion odometry, better performance in scenes with drastic changes in light

VIW-Fusion An visual-inertial-wheel fusion odometry VIW-Fusion is an optimization-based viusla-inertial-wheel fusion odometry, which is developed as a

庄庭达 248 Nov 29, 2022
Seam is a pin-based node editor for OpenFrameworks that makes prototyping visual systems easier and faster.

seam Seam is a pin-based node editor for openFrameworks built using: openFrameworks Dear ImGui the node editor extension for ImGui It is heavily WIP,

Austin Clifton 2 Jan 2, 2022
This repo includes SVO Pro which is the newest version of Semi-direct Visual Odometry (SVO) developed over the past few years at the Robotics and Perception Group (RPG).

rpg_svo_pro This repo includes SVO Pro which is the newest version of Semi-direct Visual Odometry (SVO) developed over the past few years at the Robot

Robotics and Perception Group 1k Nov 29, 2022
Sharpmake is an open-source C#-based solution for generating project definition files, such as Visual Studio projects and solutions, GNU makefiles, Xcode projects, etc.

Sharpmake Introduction Sharpmake is a generator for Visual Studio projects and solutions. It is similar to CMake and Premake, but it is designed for s

Ubisoft 777 Nov 25, 2022