==1117== Invalid free() / delete / delete[] / realloc() ==1117== at 0x4CB3F9B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1117== by 0x40717F3: reclaim_gaps (dynlink.c:508) ==1117== by 0x4072D1E: load_library (dynlink.c:1061) ==1117== by 0x4073893: load_preload (dynlink.c:1156) ==1117== by 0x4073893: __dls3 (dynlink.c:1619) ==1117== by 0x40734ED: __dls2 (dynlink.c:1441) ==1117== by 0x4075BBF: ??? (in /usr/lib/libc.so) ==1117== by 0x1: ??? ==1117== by 0x1FFF000DBE: ??? ==1117== by 0x1FFF000DC8: ??? ==1117== Address 0x4ebe180 is in a rw- mapped file /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment
What makes you think that is in it's own code, that look like it is in the C library or the dynamic linker?
When I comment out all of my free()'s, valgrind continues to complain "Invalid free()", and also indicates sections in the valgrind code, not my code.
The only reference to valgrind in that stack trace is to our replacement free routine which has detected the problem - the actual problem is in the dynlink.c code about that which has apparently passed an invalid pointer to free.
I do not see this behavior with earlier versions of valgrind such as 3.12. It’s worth pointing out that this fallacious free() warning is happening on Void Linux, compared to no fallacious warnings in Debian.
Look there is basically nothing we can do with the information you have provided - the stack trace is incomplete because the symbols appear to have been stripped and you're using an obscure distribution that I doubt any of us have. There is nothing in the information you have provided that indicates a bug in valgrind. That is pretty much all I can say on the information currently available - maybe there is a bug in valgrind, maybe there isn't, but we have no way of determining that for sure and all indication are that there isn't.
This is nothing to do with Valgrind. Closing as invalid. If you have further information indicating that it is a bug in Valgrind, feel free to reopen.