Il giorno ven, 16/11/2018 alle 06.17 +0100, Daniel Glöckner ha scritto: > Hi, > > On Fri, Nov 16, 2018 at 12:04:55AM +0100, Guido Trentalancia wrote: > > It is not possible to distinguish an address that was never > > allocated > > from an address that has already been freed. > > See > https://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-C > hecking.html > > The mcheck function causes each allocated block to be prefixed with > a magic number that is set to another magic number if the block is > freed. If there is no magic number, the memory was never allocated > or is in the middle of another block. If the magic 0xd8675309 is > found, it is a double free. The magic value will never be found in > unallocated regions because the Linux Kernel guarantees that new > pages are filled with zeros to not leak any sensitive information > from other applications or the kernel. > > Some checkers like Valgrind and DUMA try to avoid to reuse freed > regions for following allocations to better catch double frees and > use after frees. If you run Valgrind on an application that does > a double free as per my definition, Valgrind will tell you that > free was called 0 bytes inside a block freed in the past. > > > > If you call free on a random address, the symptom might sometimes > > > be > > > a double free, but the error does not deserve to be called that > > > way. > > > > In any way, the error is always called "double free or corruption" > > by > > the library and that's what people normally refer to it, so I am > > sure > > the comment is correct and fit for the purpose ! > > The error is called "double free or corruption" because by default > Glibc does not bother spending the overhead to distinguish the two.
It is outside the scope of this patch to distinguish between the two cases. The *important point* here is to prevent the error condition. The error reporting is demanded to glibc. And, as already explained, you are referred to glibc for further discussions about the error condition, as they are certainly off-theme here... This is just being pedantic ! Guido _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
