Personally I'm a bit sad that ~20 years old code we all depend on has so obvious bugs.
I found this issue after finding that all 3 glibc malloc memory use info functions (malloc_stats(), mallinfo() and malloc_info()) are bugged and report completely wrong numbers (bug 24026, bug 21556).
For malloc_stats() it was an integer overflow due to `unsigned int` being used for counting bytes.It is very well known among programmers for decades that `unsigned int` is not the right type for buffer lengths.At that point, I just searched for "unsigned int" in malloc.c to see if there are any similar problems, and found this realloc() bug within a minute.
It seems nobody does in practice read the code of fundamental components running on billions of devices.
---
How can we arrive at good software that does nontrivial things, if even casual reading reveals serious issues in the basic building blocks we all use?
2 comments
[ 3.5 ms ] story [ 9.2 ms ] thread---
Personally I'm a bit sad that ~20 years old code we all depend on has so obvious bugs.
I found this issue after finding that all 3 glibc malloc memory use info functions (malloc_stats(), mallinfo() and malloc_info()) are bugged and report completely wrong numbers (bug 24026, bug 21556).
For malloc_stats() it was an integer overflow due to `unsigned int` being used for counting bytes. It is very well known among programmers for decades that `unsigned int` is not the right type for buffer lengths. At that point, I just searched for "unsigned int" in malloc.c to see if there are any similar problems, and found this realloc() bug within a minute.
It seems nobody does in practice read the code of fundamental components running on billions of devices.
---
How can we arrive at good software that does nontrivial things, if even casual reading reveals serious issues in the basic building blocks we all use?