Il giorno gio, 15/11/2018 alle 23.35 +0100, Daniel Glöckner ha scritto: > On Thu, Nov 15, 2018 at 10:36:31PM +0100, Guido Trentalancia wrote: > > But this seems just another meaningless and "out of theme" > > discussion, not related to sigrok in any manner and which does not > > improve it, but rather deteriorate it! > > I just can't let the discussion end here. > > To me a double free is calling free twice on the same address > where at the time of the first call there was a memory region > starting at that address that was allocated with a function that > returns memory to be deallocated with free (i.e. malloc, realloc, > posix_memalign, etc.). > > If you call free on an address that was never allocated, it's not > a double free.
It is not possible to distinguish an address that was never allocated from an address that has already been freed. Therefore the two situations are perfectly equivalent ! > If you call free on an address that was allocated directly with mmap > or brk, it's not a double free. > If you call free on an address in the middle of a region allocated > with malloc, it's not a double free. It does not produce the same error. Therefore, you are talking about something different which cannot be compared directly. > 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 *important point* here is avoiding to call g_free() there, otherwise a segmentation fault occurs ! This bug has been introduced here: commit 13f2b9d789fdc7130c0f31b88319bd0f3445109a Date: Fri Oct 25 18:15:00 2013 +0200 hameg-hmo: Add initial working driver version. and then remarked here: commit 89280b1a4c0675b1383ccc6a5a63e8a2a6add05e Date: Tue Dec 3 16:48:21 2013 +0100 hameg-hmo: Minor cosmetics, coding-style fixes. So, it has always existed (for 5 years !). I am glad I have spotted it and promptly fixed it after just a couple of weeks of using sigrok. The rest is just noise, but you can still try to file a bug with glibc, if you believe that the error definition is wrong. I am *perfectly* fine with the way things are in glibc... And I have nothing else to add to this discussion which sounds really pointless to me ! Guido > Just my two cents > > Daniel _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel