Bug 331550

Summary:	Detect the potential of mis-malloc/free in different libraries
Product:	[Developer tools] valgrind	Reporter:	Greg Maxwell <gmaxwell>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	REPORTED ---
Severity:	wishlist	CC:	pjfloyd, sam, tom
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Greg Maxwell 2014-02-26 20:12:16 UTC

It would be helpful if memcheck could detect when memory allocated with malloc in the context of one library is freed using the free() from another library or the calling application.

Mismatched allocators can lead to bugs if the two codebases are later compiled with different allocators. This is a rare class of bugs when you develop on Linux but becomes much more common when that code later runs on an embedded system or on Windows— so it can go undetected for a long time.

One way to achieve this would be to use the existing malloc/free overrides but just use a different override address for each dynamic linking context, track which one was used with the allocations, and verify agreement on realloc/free.


Reproducible: Sometimes

Comment 1 Tom Hughes 2014-02-26 22:04:10 UTC

The only problem is that it is completely normal for memory allocated by one shared library to be freed by another - many functions in glibc return pointers to memory allocated with malloc that the caller is expected to free for example.

Comment 2 Paul Floyd 2023-10-15 05:56:16 UTC

The problem isn't malloc and family being called _from_different libraries. The problem is if there are calls to versions of malloc _in_ different libraries.

Do we have a fast way to tell which library (or exe) contains used allocation functions?