src/win32/w32_crtdbg_stacktrace.c


Log

Author Commit Date CI Message
Patrick Steinhardt 496b0df2 2018-03-14T10:28:50 win32: crtdbg: provide independent `free` function Currently, the `git__free` function is being defined in a single place, only, disregarding whether we use our standard allocators or the crtdbg allocators. This makes it a bit harder to convert our code base to use pluggable allocators, and furthermore makes the border between our two allocators a bit more blurry. Implement a separate `git__crtdbg__free` function for the crtdbg allocator in order to completely separate both allocator implementations.
Patrick Steinhardt aab8f87b 2018-03-14T10:27:13 win32: crtdbg: internalize implementation of allocators The crtdbg allocators are currently being implemented as inline functions as part of the "w32_crtdbg_stacktrace.h" header. As we are moving towards pluggable allocators with the help of function pointers, though, we cannot make use of inlining anymore. Instead, we can only have a single implementation of these allocating functions. Move all implementations of the crtdbg allocators into "w32_crtdbg_stacktrace.c".
Patrick Steinhardt 9865cd16 2018-03-20T14:23:49 alloc: make memory allocators use function pointers Currently, our memory allocators are being redirected to the correct implementation at compile time by simply using macros. In order to make them swappable at runtime, this commit reshuffles that by instead making use of a global "git_allocator" structure, whose pointers are set up to reference the allocator functions. Like this, it becomes easy to swap out allocators by simply setting these function pointers. In order to initialize a "git_allocator", our provided allocators "stdalloc" and "crtdbg" both provide an init function. This is being called to initialize a passed in allocator struct and set up its members correctly. No support is yet included to enable users of libgit2 to switch out the memory allocator at a global level.
Patrick Steinhardt 0c7f49dd 2017-06-30T13:39:01 Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
Edward Thomson 909d5494 2016-12-29T12:25:15 giterr_set: consistent error messages Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
Jeff Hostetler 93b42728 2015-06-09T14:38:30 Include stacktrace summary in memory leak output.