Petr Salinger napsal/wrote, On 12/20/09 13:28:
please could you apply the attached patch.
In fact there have been two double free() ;-)
The 1st one is due to realloc(p,0) returns NULL,
the free(p) have been called twice in this case.
This affects only GNU/kFreeBSD.
The 2nd one is due to cam_close_device(cam_dev) called twice
under some condition. This affects both pristine FreeBSD and GNU/kFreeBSD.
The patch have been tested by me and Axel, see [1].
The second one patch seems to be OK. Can you submit it into
SmartmonTools TRAC system, ticket #29 ?
https://sourceforge.net/apps/trac/smartmontools/ticket/29
The first one patch seems to mis-handle the situation where
reallocf(NonNullPtr, 0) called and inner realloc(ptr,0) failed. Then
NonNullPtr is not freeed. It si the primary purpose of reallocf()
function to free old pointer whenever the allocation succeeded or not so
caller will probably doesn't care the old pointer and memory region will
leak.
We need to know how to recognize if realloc(ptr,0) failed or not (e.g.
ptr is freed or not) in GLIBC's world. I know nothing about GLIBC's
implementation of memory allocator, so I can't help there.
Unless we are able to recognize those two cases it seems to be better to
change the code to something like this:
#ifdef __GLIBC__
static inline void * reallocf(void *ptr, size_t size) {
if (size==0)
size++;
void *rv = realloc(ptr, size);
if(rv == NULL)
free(ptr);
return rv;
}
#endif
By the way, you should move the discussion into mentioned TRAC BUG
ticket. As we are speaking about repair in SmartmonTools master
repository, we are off-topic in [email protected]
Dan
P.S. Such problem doesn't occur on FreeBSD because the allocation of
size=0 region never fail here. This implementation detail is LIBC
specific, so it says nothing about GLIBC's implementation.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
