tags 745888 +upstream
thanks
Hi,
On 15:41 Mon 19 May , Steve Graham wrote:
> Same behaviour as in previous report - jmtpfs returns with no error,
> but any access to the
> supposedly mounted filesystem hangs until the jmtpfs process is
> killed.
>
> Replacing the file /usr/lib/x86_64-linux-gnu/libmtp.so.9.1.0 (400744
> bytes) from the current version
> on unstable, AMD64, 1.1.6-51-g1a2669c~ds0-1, with
> /usr/lib/x86_64-linux-gnu/libmtp.so.9.1.0 (388392
> bytes) from 1.1.6-20-g1b9f164-1~bpo70+1 seems to fix the problem. (I
> downloaded the deb from
> wheezy-backports, and extracted and copied over the library as a quick test.)
>
> Note that these two libraries with identical version numbers are
> different files.
This is an upstream issue. Bisecting between upstream commits 1b9f164
(good) and 1a2669c (bad) points out:
b9a840c Async buffering for high-speed transfers.
as the culprit. Reverting this commit makes jmtpfs work again for me.
Now, this commit introduces a threaded bulk transfer worker for libusb
1.x. A backtrace of the worker thread from a stuck jmtpfs process looks like
this:
Thread 3 (Thread 0x7f879a76c700 (LWP 22394)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1 0x00007f879ce75fe4 in libusb_wait_for_event (ctx=ctx@entry=0x1120b80,
tv=tv@entry=0x7f879a76afa0)
at ../../libusb/io.c:1832
#2 0x00007f879ce76487 in libusb_handle_events_timeout_completed
(ctx=ctx@entry=0x1120b80,
tv=tv@entry=0x7f879a76afe0, completed=completed@entry=0x7f879a76b03c) at
../../libusb/io.c:2159
#3 0x00007f879ce76540 in libusb_handle_events_completed
(ctx=ctx@entry=0x1120b80,
completed=completed@entry=0x7f879a76b03c) at ../../libusb/io.c:2236
#4 0x00007f879ce76d91 in sync_transfer_wait_for_completion
(transfer=transfer@entry=0x7f8794004c48)
at ../../libusb/sync.c:50
#5 0x00007f879ce76e69 in do_sync_bulk_transfer (dev_handle=0x1130ec0,
endpoint=<optimized out>,
buffer=buffer@entry=0x7f8794000be0 "\f", length=12,
transferred=transferred@entry=0x7f879a76b0e4,
timeout=20000, type=type@entry=2 '\002') at ../../libusb/sync.c:179
#6 0x00007f879ce771f4 in libusb_bulk_transfer (dev_handle=<optimized out>,
endpoint=<optimized out>,
data=data@entry=0x7f8794000be0 "\f", length=<optimized out>,
transferred=transferred@entry=0x7f879a76b0e4, timeout=<optimized out>) at
../../libusb/sync.c:256
#7 0x00007f879d0bb35c in ptp_write_func (size=size@entry=12, data=0x1130c50,
written=written@entry=0x7f879a76b148, handler=0x7f879a76b150,
handler=0x7f879a76b150)
at libusb1-glue.c:1508
#8 0x00007f879d0bd92d in ptp_usb_sendreq (params=0x11232f0,
req=0x7f879a76b770) at libusb1-glue.c:1700
#9 0x00007f879d0a9b6d in ptp_transaction_new (params=0x11232f0,
ptp=0x7f879a76b770,
flags=<optimized out>, sendlen=0, handler=0x7f879a76b700) at ptp.c:156
#10 0x00007f879d0a9dc9 in ptp_transaction (params=params@entry=0x11232f0,
ptp=ptp@entry=0x7f879a76b770, flags=flags@entry=2, sendlen=sendlen@entry=0,
data=data@entry=0x7f879a76b768, recvlen=recvlen@entry=0x7f879a76b764) at
ptp.c:404
#11 0x00007f879d0aacd4 in ptp_getstorageids (params=params@entry=0x11232f0,
storageids=storageids@entry=0x7f879a76b7e0) at ptp.c:1142
#12 0x00007f879d09f9f4 in LIBMTP_Get_Storage (device=0x11226f0, sortby=0) at
libmtp.c:3999
It looks like it ends up in some kind of deadlock.
Regards,
Apollon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
