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.
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
Show replies