libftdi Archives

Subject: Re: libftdi 1.x testing

From: Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Sun, 23 Dec 2012 18:03:06 +0100
On 10/15/2012 03:14 PM, Xiaofan Chen wrote:
> 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.

Ok, I've tackled this issue finally. It wasn't possible to fix it
without an API change, though this is not too much of an issue
for libfdti 1.x., especially for the C++ wrapper.

The code in question was a bit of a time bomb, working on the
device list / usb device pointers after calling ftdi_deinit()
was a lucky gamble even with libusb 0.x.

I hope to push out a libftdi 1.0 release candidate
on 27.12. or 28.12., 2012 ;)

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread