Just saw report that turned out to be mallocng catching a 1-byte (likely off-by-one arithmetic error) heap overflow in a major application. 😃
Conversation
And here's the offending line where they document the bug, LOL:
1
1
10
"p=malloc(5); means I can write p[7]=42; because of course malloc is actually padding up to a multiple of sizeof(long)" WTF 🤦🤦🤦
8
3
32
The best part is that this kind of thing is pretty bad for performance. redis has special support for jemalloc and should really just be using the proper APIs for this kind of thing when built with it. malloc_usable_size is bad for performance and their workaround even more so.
1
1
They should just be tracking the size of the allocation that they requested. It's undefined behavior to use malloc_usable_size to use more of an allocation than was requested with the malloc function anyway. GCC / Clang don't support doing that and will detect it as a bug...
1
jemalloc has nallocx(size, flags) to calculate the real size of an allocation without having to query an allocation. You do this before allocating and request it with the rounded amount.
Dynamic arrays as pointer -> { size, data[] } is really a performance anti-pattern.
1
It's even worse if they're relying on querying malloc. Calculating the size with modern malloc implementations will usually require reading it from out-of-line metadata. They don't use wasteful headers. Using malloc_object_size is an anti-performance approach if anything.
1
I just saw this thread. Very insightful! I assumed code involving memory allocations/alignment is in the name of performance. Now it just sounds like bad code.
1
It never makes much sense to query the allocator for the size of the allocation. You can also get significantly better performance from an allocation API requiring passing the size for deallocation. Real world C programs are often going to provide an incorrect value though...