[Bug 259294] [libc] add a freeres function

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 20 Oct 2021 06:10:37 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259294

            Bug ID: 259294
           Summary: [libc] add a freeres function
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: pjfloyd@wanadoo.fr

Summary
~~~~~~~

This is a request to add a freeres function to libc.


Motivation
~~~~~~~~~~

This function would be used by Valgrind (and conceivably other similar tools).
The purpose is to free any "still reachable" memory on a clean exit. For
instance, this would include buffers allocated for I/O.

The freeres function doesn't get called by libc and in fact never gets called
for applications running in a regular environment. However, Valgrind will look
to see if it is present and call it (unless a command line flag has been
specified not to do so).

Current Status
~~~~~~~~~~~~~~

On Linux, GNU libc has such a function (as  does libstdc++,__gnu_cxx::__freeres
).

On FreeBSD, libc++ does not allocate any buffers whose lifetime is not managed
by the runtime. The libstdc++ function __gnu_cxx::__freeres is used in the same
way as it is on Linux.

For FreeBSD libc, the default suppression mechanism is used. Whilst this is a
reasonable solution, some users seem to find it disturbing and want to see
strictly zero leaks/memory use in the final summary.


This means that a 'printf("Hell, World!\n");' C application will have the
following summary from Valgring memcheck of FreeBSD

==76307== HEAP SUMMARY:
==76307==     in use at exit: 4,096 bytes in 1 blocks
==76307==   total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==76307== 
==76307== LEAK SUMMARY:
==76307==    definitely lost: 0 bytes in 0 blocks
==76307==    indirectly lost: 0 bytes in 0 blocks
==76307==      possibly lost: 0 bytes in 0 blocks
==76307==    still reachable: 0 bytes in 0 blocks
==76307==         suppressed: 4,096 bytes in 1 blocks

On Linux, the "in use at exit" is 0 and there is no "suppressed" line at the
end.

-- 
You are receiving this mail because:
You are the assignee for the bug.