libftdi Archives

Subject: Re: libftdi 1.x testing

From: Anders Larsen <al@xxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Cc: Xiaofan Chen <xiaofanc@xxxxxxxxx>
Date: Thu, 11 Oct 2012 14:02:38 +0200
Hi Xiaofan,

On 2012-10-10 04:22:01, Xiaofan Chen wrote:
> On Tue, Oct 9, 2012 at 10:27 PM, Xiaofan Chen <xiaofanc@xxxxxxxxx> wrote:
> > Somehow I got segmental fault with the find_all_pp example
> > under Mac OS X 10.7.5. This is with the latest git.
> 
> I think it is not a OS specific problem.

AFAICT there's a bug in List::find_all() dereferencing free'd pointers:

At line #627 List::find_all() calls ftdi_usb_find_all() to obtain a list
of matching devices. This list (struct ftdi_device_list) contains a
pointer to the corresponding libusb_device.

Before creating the Ftdi::List object at line #629 List::find_all()
calls ftdi_deinit() at line #628 which in turn closes and deallocates
the a/m libusb_device.

At line #461 the Ftdi::List constructor traverses the ftdi_device_list
and at line #464 passes the (closed and deallocated) libusb_device
pointer to a fresh Ftdi::Context object.

Then Ftdi::Context::get_strings() is called at line #465 which in turn
calls ftdi_usb_get_strings() at line #306 passing said toxic pointer.
Boom!

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...

Given that the code in question hasn't changed since four years ago the
breakage was probably caused by semantic changes to libftdi proper.

Cheers
Anders

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

Current Thread