On Sep 08 Lee Cewd wrote:
> Hello,
>
> Two weeks ago, I post a message about a memory leak problem on mailing
> lists.
>
> The following result is that I use valgrind to check this problem.
>
> 3067120 (3066560 direct, 560 indirect) bytes in 10952 blocks are
> definitely lost in loss record 36 of 36 at 0x4029F6F : malloc ()
> by 0x405B1B5 : ??? (in usr/lib/libraw1394.so.11.0.1)
> by 0x405B492 : ??? (in usr/lib/libraw1394.so.11.0.1)
> by 0x405BF24 : fw_loop_iterate (in usr/lib/libraw1394.so.11.0.1)
> by 0x405C197 : ??? (in usr/lib/libraw1394.so.11.0.1)
> by 0x405D6F8 : fw_write (in usr/lib/libraw1394.so.11.0.1)
> by 0x405A292 : raw1394_write (in usr/lib/libraw1394.so.11.0.1)
> by 0x805A0F2 : main (main.cpp:121)
>
> Recently, I modify libraw1394-2.1.0 source code.
>
> fw.c:
>
> static int
> handle_arm_request(raw1394handle_t handle, struct address_closure *ac,
> int tcode, unsigned long long offset, int source_node_id,
> int card, unsigned kernel_handle, size_t length, void *data)
> {
> ......
> - return fwhandle->arm_tag_handler(handle, allocation->tag, type,length, &rrb->request_response);
> + int retval;
> + retval = fwhandle->arm_tag_handler(handle, allocation->tag, type, length, &rrb->request_response);
> + free(rrb);
> + return retval;
> }
>
> This way can solve my problem.
>
> Best Regards,
>
> Cewd
Thank you very much for the earlier report and for this patch. Looks good
to me. I will try to test it with a few libraw1394 based applications as
soon as I can, and get it released.
--
Stefan Richter
-=====-===-= =--= -=--=
http://arcgraph.de/sr/
|
