libtorrent icon indicating copy to clipboard operation
libtorrent copied to clipboard

Disabling malloc_usable_size for -D_FORTIFY_SOURCE=3 compatibility

Open kpcyrd opened this issue 2 years ago • 3 comments

Please provide the following information

libtorrent version (or branch): RC_2_0

platform/architecture: Linux

compiler and compiler version: gcc 12

Arch Linux is preparing switching to -D_FORTIFY_SOURCE=3, upon inspection if all packages I noticed libtorrent uses a function called malloc_usable_size. This function is "for diagnostic purposes only" and should not be used in release builds, as it's going to be considered a fatal memory violation with -D_FORTIFY_SOURCE=3 (source).

Fortunately there's only one place in which libtorrent is using malloc_usable_size, so it would be trivial to patch downstream:

diff --git a/include/libtorrent/aux_/buffer.hpp b/include/libtorrent/aux_/buffer.hpp
index 7d8fe0da2..ce6cf21d4 100644
--- a/include/libtorrent/aux_/buffer.hpp
+++ b/include/libtorrent/aux_/buffer.hpp
@@ -87,17 +87,7 @@ public:
                m_begin = static_cast<char*>(std::malloc(static_cast<std::size_t>(size)));
                if (m_begin == nullptr) aux::throw_ex<std::bad_alloc>();
 
-               // the actual allocation may be larger than we requested. If so, let the
-               // user take advantage of every single byte
-#if (defined __GLIBC__ && !defined __UCLIBC__) || defined __FreeBSD__
-               m_size = static_cast<difference_type>(::malloc_usable_size(m_begin));
-#elif defined _MSC_VER
-               m_size = static_cast<difference_type>(::_msize(m_begin));
-#elif defined __APPLE__
-               m_size = static_cast<difference_type>(::malloc_size(m_begin));
-#else
                m_size = size;
-#endif
        }
 
        // allocate an uninitialized buffer of the specified size

kpcyrd avatar Sep 15 '23 12:09 kpcyrd

right, this is an attempted optimization, to make use of as much of the allocation as possible before having to realloc. It can easily be circumvented. You say it's for diagnostic purposes only, is that referring to the glibc function?

arvidn avatar Sep 27 '23 11:09 arvidn

Yes, from the glibc malloc_usable_size documentation:

The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of alignment and minimum size constraints. Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation.

The main use of this function is for debugging and introspection.

kpcyrd avatar Sep 27 '23 17:09 kpcyrd