Re: [boost] [Root Pointer] Deterministic C++ memory manager (update)

Subject: Re: [boost] [Root Pointer] Deterministic C++ memory manager (update)
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2017-12-24 22:29:14

On 11/15/2017 12:40 AM, Phil Bouchard via Boost wrote:
> Greetings,
> 
> I wanted to give an update to the community regarding the memory manager 
> I wrote called: Root Pointer.
> 
> I now have a working template to solve all memory leaks in C++ and C but 
> both requires some meta data generator. The code can be found here; it 
> is working but not polished:
> https://github.com/philippeb8/root_ptr
> 
> In this code we can find:
> 
>  Â  - node_ptr: main class of the smart pointer / memory manager.
>  Â  - root_ptr: generic derived class that includes an "iterator" and a 
> pointer to the name of the instance (for debugging purposes).
> 
> Also I commented some code that logs the exact location of the memory leak.
> 
> Furthermore I would like to bring some observations that I found in the 
> C and the C++ language:
> 
>  Â  - Pointers and iterators are not the same; i.e. pointers should point 
> to allocated blocks only and shouldn't have arithmetic operators while 
> iterators shouldn't be used to deallocate anything.
>  Â  - C pointers can only point to dynamic arrays (size known at run-time).
>  Â  - C++ pointers can point to both inherited objects and static arrays 
> (size known at compile-time). This creates a problem (see attached: 
> array_inherited_pointer.cpp).
>  Â  - std::array<T> should have constructors with T objects that have no 
> default constructor.
> 
> Lastly, before I submit anything, I will have to propose a way to apply 
> a template function to all non-static member variables of a class. This 
> will require implicit meta data generation. This idea is not new as 
> other libraries such as Qt is based on meta data and they certainly 
> could make us of this. For the moment I have a parser that does the job 
> correctly by specializing a boost::proxy() template function but 
> eventually this will have to be integrated into the standards.
> 
> Hopefully this is an important milestone!
> 
> 
> Regards,
> Phil Bouchard
> www.fornux.com

Here is yet another important update:
https://github.com/philippeb8/root_ptr/tree/master/include/boost/smart_ptr

I've been testing Fornux C Leak Detector (modified Clang which uses 
Root.Ptr) with a modified libarchive 3.2.2:
https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b

And I've got the following diagnosis:

[2017-12-24 16:20:04.536311] [0x00007fd0b34f3fc0] [info]    <cycle>: 0# 
archive_read_open_filenames(boost::node_proxy&, 
boost::root_ptr<std::vector<archive, std::allocator<archive> > >, 
boost::root_ptr<std::vector<boost::root_ptr<std::vector<char, 
std::allocator<char> > >, 
std::allocator<boost::root_ptr<std::vector<char, std::allocator<char> > 
 > > > >, unsigned long) at 
/home/philippeb8/devel/1/libarchive-3.2.2/libarchive/archive_read_open_filename.c:164 

[2017-12-24 16:20:04.614519] [0x00007fd0b34f3fc0] [info]    "p": 0# 
gnu_clear_sparse_list(boost::node_proxy&, 
boost::root_ptr<std::vector<tar, std::allocator<tar> > >) at 
/home/philippeb8/devel/1/libarchive-3.2.2/libarchive/archive_read_support_format_tar.c:2119 

[2017-12-24 16:20:04.677372] [0x00007fd0b34f3fc0] [info]    "tar": 0# 
archive_read_format_tar_cleanup(boost::node_proxy&, 
boost::root_ptr<std::vector<archive_read, std::allocator<archive_read> > 
 >) at 
/home/philippeb8/devel/1/libarchive-.2.2/libarchive/archive_read_support_format_tar.c:237 

[2017-12-24 16:20:04.734981] [0x00007fd0b34f3fc0] [info] 
"client_buff": 0# ~archive_read_filter at 
/home/philippeb8/devel/1/libarchive-3.2.2/libarchive/archive_read_private.h:82

"p" and "tar" being explicitly deleted in the code leaves us with with 
"client_buff" that leaks in this version of libarchive (3.2.2). This 
proves Root.Ptr works with commercial software and doesn't slow down the 
final app (in contrast with Herb Sutter's deferred_ptr, Valgrind, 
Parasoft Insure++ and Rationale Purify).

On another note, it would be great to throw an exception on segmentation 
faults. This way it would be possible to automatically generate a stack 
dump using Fornux C Leak Detector because it can add the necessary 
information on the stack.

Merry Christmas and Happy New Year!
-Phil
www.fornux.com