Thanks for that, I have prog here which points to malloc, I can see buf was
pointer, allocated memory by malloc, it gets filled, but the last few lines
of code, doesnot free that, also it does fee priv->con... and then it
assigns, looks not correct.
static int cache_active_config(struct libusb_device *dev, int fd,
603<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L603>
int active_config)
604<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L604>
{
605<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L605>
struct linux_device_priv *priv = __device_priv(dev);
606<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L606>
struct libusb_config_descriptor config;
607<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L607>
unsigned char tmp[8];
608<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L608>
unsigned char *buf;
609<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L609>
int idx;
610<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L610>
int r;
611<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L611>
612<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L612>
if (active_config == -1) {
613<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L613>
idx = 0;
614<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L614>
} else {
615<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L615>
r = usbi_get_config_index_by_value(dev, active_config, &idx);
616<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L616>
if (r < 0)
617<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L617>
return r;
618<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L618>
if (idx == -1)
619<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L619>
return LIBUSB_ERROR_NOT_FOUND;
620<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L620>
}
621<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L621>
622<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L622>
r = get_config_descriptor(DEVICE_CTX(dev), fd, idx, tmp, sizeof(tmp));
623<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L623>
if (r < 0) {
624<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L624>
usbi_err(DEVICE_CTX(dev), "first read error %d", r);
625<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L625>
return r;
626<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L626>
}
627<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L627>
628<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L628>
usbi_parse_descriptor(tmp, "bbw", &config, 1);
629<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L629>
buf = malloc(config.wTotalLength);
630<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L630>
if (!buf)
631<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L631>
return LIBUSB_ERROR_NO_MEM;
632<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L632>
633<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L633>
r = get_config_descriptor(DEVICE_CTX(dev), fd, idx, buf,
634<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L634>
config.wTotalLength);
635<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L635>
if (r < 0) {
636<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L636>
free(buf);
637<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L637>
return r;
638<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L638>
}
639<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L639>
640<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L640>
if (priv->config_descriptor)
641<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L641>
free(priv->config_descriptor);
642<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L642>
priv->config_descriptor = buf;
643<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L643>
return 0;
644<http://www.libusb.org/browser/libusb/os/linux_usbfs.c?rev=217f57617e0cff0d1bd6d726b243f04c6b179773#L644>
}
On Wed, Jan 20, 2010 at 3:21 PM, Bram De Wachter <[email protected]> wrote:
>
> 2010/1/20 Vasanta <[email protected]>
>
> Can some valgrind expert analyze those logs, looklike malloc happening in
>> libusb, which are not freed.
>>
>>
>>
>>
>>
>>
>> On Wed, Jan 20, 2010 at 2:48 PM, Vasanta <[email protected]> wrote:
>>
>>> I ran again, this time it points to maloc(), Is this makes sense fro
>>> memory leak?.
>>>
>>>
> Of course it is malloc()... but the real question is who is calling
> malloc() and better, who is loosing track of the memory returned by malloc.
>
> Let me give an example (although I am sure these things are clearly
> documented in the valgrind manual):
>
> char * ptr = 0; // Global pointer
>
> f() {
> ptr = malloc(1024); // Allocate here
> }
>
> g() {
> ptr = 0;
> }
>
> main() {
> f();
> // No bytes lost now since ptr is still pointing to it
> g(); // Now this causes a memory leak since nothing is pointing to the
> 1024 bytes and the memory can never be free()d
> }
>
> In this case the output of valgrind will indicate that the memory allocated
> by malloc() in f() is lost when the program exits.
> As you can clearly see, the problem is not in f() but rather in g(). And
> for sure, malloc() is not the problem.
>
> Hopes this helps,
> Bram.
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
