Quantcast

Asynchronous reading doesn't timeout

classic Classic list List threaded Threaded
3 messages Options
jry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Asynchronous reading doesn't timeout

jry
I have found strange behavior of ftdi_read_data_submit() and ftdi_transfer_data_done() while receiving data from FT245RL. When device returns less bytes than expected, ftdi_transfer_data_done() freezes infinitely. I would expect it will return after timeout. Am I using it wrong?

I have found similar old thread in mailing list archive:

I'm using latest libftdi 1.3.

Thank you for any suggestion
Jan


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Asynchronous reading doesn't timeout

Thomas Jarosch
Hi Jan,

On Sunday, 6. November 2016 22:13:01 jry wrote:

> I have found strange behavior of ftdi_read_data_submit()
> and ftdi_transfer_data_done() while receiving data from FT245RL. When
> device returns less bytes than expected, ftdi_transfer_data_done() freezes
> infinitely. I would expect it will return after timeout. Am I using it
> wrong?
>
> I have found similar old thread in mailing list archive:
> http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00001.html
>
> I'm using latest libftdi 1.3.

perhaps attaching strace to the hanging process might shed some light on
this. Or attach gdb and get a backtrace to see where it's stuck.

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

jry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Asynchronous reading doesn't timeout

jry
Hi Thomas,

Thank you for your response. Here is gdb backtrace:

#0 ftdi_transfer_data_done (tc=0x64a830) at /home/john/work/sigrok/libftdi/src/ftdi.c:1742
#1 0x00007ffff7b5bc85 in sigma_write_read (wbuf=0x7fffffffde10, wbuf_len=130, rbuf=0x61b450, rbuf_len=43008, devc=0x6425a0) at src/hardware/asix-sigma/protocol.c:165
#2 0x00007ffff7b5c1c7 in sigma_read_dram_rows (start_row=0, num_rows=42, data=0x61b450 "'\354\031\205\031\005\032\005\032\005\032\205\032\005\033\005.\354\033\205\033\205\034\005\034\005\034\205\034\205\035\005\066\354\035\205\036\205\036\005\036\005\036\205\037\205\037\005>\354 \205 \205 \005 \005!\205!\205!\005E\354\"\005\"\205\"\205\"\005#\005#\205#\205L\354$\005$\005$\205$\205%\005%\005%\205S\354&\005&\005&\205&\205'\005'\005'\205Z\354!\205(\005(\005(\205)\205)\005)\005a\354)\205*\205*\005*\005+\205+\205+\005h\354)\005,\205,\205,\005-\005-\205-\205o\354-\005.\005.\205.\205/\005/\005/\205w\354\060\005\060\005\060\205\061\005\061\005\061\005\061\205~\354\062\005\062\005\062\205"..., devc=0x6425a0) at src/hardware/asix-sigma/protocol.c:304
#3 0x00007ffff7b5dd14 in download_capture (sdi=0x62f2d0) at src/hardware/asix-sigma/protocol.c:1099
#4 0x00007ffff7b5de88 in sigma_capture_mode (sdi=0x62f2d0) at src/hardware/asix-sigma/protocol.c:1150
#5 0x00007ffff7b5dee2 in sigma_receive_data (fd=-1, revents=0, cb_data=0x62f2d0) at src/hardware/asix-sigma/protocol.c:1170
#6 0x00007ffff7b2ef3a in fd_source_dispatch (source=0x630720, callback=0x7ffff7b5de91 <sigma_receive_data>, user_data=0x62f2d0) at src/session.c:130
#7 0x00007ffff764005a in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007ffff7640400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x00007ffff7640722 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x000000000040a28e in run_session () at session.c:700
#11 0x00000000004055de in main (argc=11, argv=0x7fffffffe288) at main.c:267

I can see infinite loop in function ftdi_transfer_data_done() on following lines:

    while (!tc->completed)
    {
        ret = libusb_handle_events_timeout_completed(tc->ftdi->usb_ctx,
                &to, &tc->completed);
        if (ret < 0)
        ...
    }

libusb_handle_events_timeout_completed() returns ret == 0 and also tc->completed is 0.

Inside libusb_handle_events_timeout_completed() function it is going through:

int API_EXPORTED libusb_handle_events_timeout_completed(libusb_context *ctx, struct timeval *tv, int *completed) { int r; struct timeval poll_timeout; USBI_GET_CONTEXT(ctx); r = get_next_timeout(ctx, tv, &poll_timeout);
<<< r == 0 if (r) { /* timeout already expired */ return handle_timeouts(ctx); } retry: if (libusb_try_lock_events(ctx) == 0) { if (completed == NULL || !*completed) { <<< completed == 0 /* we obtained the event lock: do our own event handling */ usbi_dbg("doing our own event handling"); r = handle_events(ctx, &poll_timeout); <<< r == 0 } <<< see ctx dump below libusb_unlock_events(ctx);
return r; }
print *ctx
$2 = {debug = 0, debug_fixed = 0, event_pipe = {9, 10}, usb_devs = {prev = 0x64a980, next = 0x641cf0}, usb_devs_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, open_devs = {prev = 0x62f0e0, next = 0x62f0e0}, open_devs_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, hotplug_cbs = {prev = 0x62e2f0, next = 0x62e2f0}, hotplug_cbs_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, flying_transfers = {prev = 0x641df8, next = 0x641df8}, flying_transfers_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, fd_added_cb = 0x0, fd_removed_cb = 0x0, fd_cb_user_data = 0x0, events_lock = {__data = {__lock = 1, __count = 0, __owner = 18874, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000\272I\000\000\001", '\000' <repeats 26 times>, __align = 1}, event_handler_active = 1, event_handling_key = 3, event_waiters_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, event_waiters_cond = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, event_data_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, event_flags = 0, device_close = 0, ipollfds = {prev = 0x631518, next = 0x62e588}, pollfds = 0x63c240, pollfds_cnt = 3, hotplug_msgs = {prev = 0x62e450, next = 0x62e450}, completed_transfers = {prev = 0x62e460, next = 0x62e460}, timerfd = 11, list = {prev = 0x7ffff6d11760 <active_contexts_list>, next = 0x61a218}}

Please note that ftdi_transfer_data_done() function works fine when submitted "read" buffer
(in function ftdi_read_data_submit) has the exact or smaller size than number of bytes we
receive from the device. It hangs only when device returns smaller response than we required.

Do you have any idea?

Best regards
Jan


On Tue, Nov 8, 2016 at 1:12 PM, Thomas Jarosch <[hidden email]> wrote:
Hi Jan,

On Sunday, 6. November 2016 22:13:01 jry wrote:
> I have found strange behavior of ftdi_read_data_submit()
> and ftdi_transfer_data_done() while receiving data from FT245RL. When
> device returns less bytes than expected, ftdi_transfer_data_done() freezes
> infinitely. I would expect it will return after timeout. Am I using it
> wrong?
>
> I have found similar old thread in mailing list archive:
> http://developer.intra2net.com/mailarchive/html/libftdi/2014/msg00001.html
>
> I'm using latest libftdi 1.3.

perhaps attaching strace to the hanging process might shed some light on
this. Or attach gdb and get a backtrace to see where it's stuck.

Cheers,
Thomas




libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Loading...