On Thu, Oct 11, 2012 at 8:02 PM, Anders Larsen <al@xxxxxxxxxxx> wrote:
> I'm not sure how to fix this properly - just removing the ftdi_deinit()
> call at line #628 would cause a resource leak, and creating the
> Ftdi::List object before calling ftdi_deinit() would fix this particular
> crash but would probably cause the application to crash at a later stage
> instead...
Thanks. Commenting out #628 indeed makes the program run.
And Valgrind indeed finds some memory leaks.
mymacmini:examples xiaofanc$ pwd
/Users/xiaofanc/work/libftdi/libftdi/build/examples
mymacmini:examples xiaofanc$ ./find_all_pp -v 0403 -p cff8
Found devices ( VID: 0x403, PID: 0xcff8 )
------------------------------------------------
FTDI (0x7fbd4bd04bd0): Amontec, Amontec JTAGkey-2, 53T9XDR4 (Open OK)
mymacmini:examples xiaofanc$ valgrind --tool=memcheck
--leak-check=full --track-origins=yes ./find_all_pp -v 0403 -p cff8
...
==43409== LEAK SUMMARY:
==43409== definitely lost: 4,640 bytes in 4 blocks
==43409== indirectly lost: 0 bytes in 0 blocks
==43409== possibly lost: 24 bytes in 1 blocks
==43409== still reachable: 151,717 bytes in 823 blocks
==43409== suppressed: 0 bytes in 0 blocks
...
> Given that the code in question hasn't changed since four years ago the
> breakage was probably caused by semantic changes to libftdi proper.
--
Xiaofan
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|