This was already mentioned in #353 and can be reproduced with valgrind (see output below). I would assume this is unintentional leaking as the reported blocks are "in use at exit".
I would also argue that the relevant code in abuf.c is not POSIX-compliant, as it is clearly stated that:
Previous versions explicitly permitted a call to realloc(p, 0) to free the space pointed to by p
and return a null pointer. While this behavior could be interpreted as permitted by this version
of the standard, the C language committee have indicated that this interpretation is incorrect.
A possible fix (although dirty) would be to add a check for a zero-len. I will add a PR, maybe we can come up with something better :)
==168846== realloc() with size 0
==168846== at 0x4846A40: realloc (vg_replace_malloc.c:1649)
==168846== by 0x404693: abuf_setup (abuf.c:56)
==168846== by 0x404E2B: axel_close.part.0 (axel.c:764)
==168846== by 0x4040CD: main (text.c:463)
==168846== Address 0x12e8b970 is 0 bytes inside a block of size 2,048 alloc'd
==168846== at 0x4846A40: realloc (vg_replace_malloc.c:1649)
==168846== by 0x404693: abuf_setup (abuf.c:56)
==168846== by 0x407C6D: conn_setup (conn.c:319)
==168846== by 0x404EEA: setup_thread (axel.c:836)
==168846== by 0x4DC7946: start_thread (pthread_create.c:444)
==168846== by 0x4E4D763: clone (clone.S:100)
==168846==
==168846== realloc() with size 0
==168846== at 0x4846A40: realloc (vg_replace_malloc.c:1649)
==168846== by 0x404693: abuf_setup (abuf.c:56)
==168846== by 0x404E3C: axel_close.part.0 (axel.c:765)
==168846== by 0x4040CD: main (text.c:463)
==168846== Address 0x12aaf280 is 0 bytes inside a block of size 111,616 alloc'd
==168846== at 0x4846A40: realloc (vg_replace_malloc.c:1649)
==168846== by 0x404693: abuf_setup (abuf.c:56)
==168846== by 0x409763: http_exec (http.c:268)
==168846== by 0x407DC2: conn_exec (conn.c:337)
==168846== by 0x404F2E: setup_thread (axel.c:838)
==168846== by 0x4DC7946: start_thread (pthread_create.c:444)
==168846== by 0x4E4D763: clone (clone.S:100)
==168846==
==168846==
==168846== HEAP SUMMARY:
==168846== in use at exit: 10,095 bytes in 24 blocks
==168846== total heap usage: 1,173 allocs, 1,149 frees, 24,896,943 bytes allocated
==168846==
==168846== LEAK SUMMARY:
==168846== definitely lost: 0 bytes in 0 blocks
==168846== indirectly lost: 0 bytes in 0 blocks
==168846== possibly lost: 0 bytes in 0 blocks
==168846== still reachable: 10,095 bytes in 24 blocks
==168846== suppressed: 0 bytes in 0 blocks
==168846== Rerun with --leak-check=full to see details of leaked memory
==168846==
==168846== For lists of detected and suppressed errors, rerun with: -s
==168846== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
This was already mentioned in #353 and can be reproduced with valgrind (see output below). I would assume this is unintentional leaking as the reported blocks are "in use at exit".
I would also argue that the relevant code in abuf.c is not POSIX-compliant, as it is clearly stated that:
A possible fix (although dirty) would be to add a check for a zero-len. I will add a PR, maybe we can come up with something better :)