whoozle / android-file-transfer-linux

Android File Transfer for Linux (and macOS!)
http://whoozle.github.io/android-file-transfer-linux/
GNU Lesser General Public License v2.1
1.46k stars 121 forks source link

Unstable usb behaviour, timeouts and freezes #12

Closed whoozle closed 9 years ago

whoozle commented 9 years ago

Configuring devices often leads to timeouts. Intercepted traffic shows that proper device response was delayed until exiting from app. libusb bug?

whoozle commented 9 years ago

might not be actual after #10

trufanov-nok commented 9 years ago

The behaviour is quite same - 1st launch is timeout, second - connect. And you could catch BUSY error if you'll be fast enough and try to connect just after USB is plugged in.

I would like to note one new detail which was observed before but wasn't reported. In case device is locked with PIN you'll get "TIMEOUT, ERROR, TIMEOUT..." loop. Where ERROR is "GetObjectHandles: invalid response code InvalidStorageID (0x2008)" and console output: "drop message 0003 201e, transaction 00000000, expected: 00000001".

whoozle commented 9 years ago

EBUSY clearly indicates that someone else uses the same usb device.

whoozle commented 9 years ago

I removed libusb and interact with usb devices directly for now, could you test the latest git revision ?

trufanov-nok commented 9 years ago

Same behaviour - one fail and then one successful attempt. Both in a loop. During failed one the app displays "timeout reaping usb urb"

whoozle commented 9 years ago

Added 3 attempts of device restart in UI, could you test please?

trufanov-nok commented 9 years ago

I have connected the device. 1st launch: I got a busy message ioctl(_fd, USBDEVFS_CLAIMINTERFACE, &interfaceNumber): Устройство или ресурс занято, which seems to be ok. Perhaps I was too fast. 2nd launch: I got timeout reaping usb urb. GUI didn't open. 3rd launch: I got vector::_M_range_check:__n (which is 0) >= this->size() (which is 0). GUI opened but empty. 4th launch: GUI started and displayed correct content.

After step 4 any time you launch the app it works correctly till you unplug it. Which is great. Only need to eliminate steps 2-3. Console:

~/android-file-transfer-linux/build/qt$ ./android-file-transfer 
upload worker started
invalid endpoint type Isoc
~/android-file-transfer-linux/build/qt$ ./android-file-transfer 
upload worker started
invalid endpoint type Isoc
device info "NOKIA"   "909"
exception timeout reaping usb urb: discard = 0
~/android-file-transfer-linux/build/qt$ ./android-file-transfer 
upload worker started
invalid endpoint type Isoc
~/android-file-transfer-linux/build/qt$ ./android-file-transfer 
upload worker started
invalid endpoint type Isoc
device info "NOKIA"   "909"
drop message 0003 201e, transaction 00000000, expected: 00000001
~/android-file-transfer-linux/build/qt$ ./android-file-transfer 
upload worker started
invalid endpoint type Isoc
device info "NOKIA"   "909"

Perhaps tomorrow I'll try to debug it if I'll be able to build it with QtCreator.

whoozle commented 9 years ago

Fixed «invalid endpoint type Isoc».

whoozle commented 9 years ago

Added logs around opening session, could try again and send logs here please? :) The most strangest thing is that first message seems to be ok, I've added GetDeviceInfo message (NOKIA 909 comes from it), so I could check that mtp actually works.

trufanov-nok commented 9 years ago

Steps are same. New console output is:

$ ./qt/android-file-transfer 
upload worker started
device info "NOKIA"   "909"
device found, opening session...
3003 ms since the last poll call
exception timeout reaping usb urb: discard = 0

$ ./qt/android-file-transfer 
upload worker started

$ ./qt/android-file-transfer 
upload worker started
device info "NOKIA"   "909"
device found, opening session...
drop message 0003 201e, transaction 00000000, expected: 00000001
session opened, starting
whoozle commented 9 years ago

What happened the second time you started an app?

trufanov-nok commented 9 years ago

I got vector::_M_range_check:__n (which is 0) >= this->size() (which is 0) message. GUI opened but empty.

whoozle commented 9 years ago

Could you uncomment mtp/backend/linux/usb/Device.cpp:173 line (HexDump("read", ....) and leave it like this until we understand what's going on? :) Maybe your device use separate mtp headers or split bulk transaction somehow.

trufanov-nok commented 9 years ago

Done: http://pastebin.com/hc8Yw6rh 1st launch - timeout reaping usb urb error. 2nd - vector::_M_range_check:__n (which is 0) >= this->size() (which is 0) error 3rd - work as expected

whoozle commented 9 years ago

Could you please repeat it once again with uncommented line Device.cpp:103, HexDump("write", ByteArray(data.data(), data.data() + r)); (HexDump("read" is needed too). I'm still puzzled about what's going on, everything looks ok for me, except duplicated session already opened message.

trufanov-nok commented 9 years ago

Done: http://pastebin.com/GevMVXuF

whoozle commented 9 years ago

Weird. I've seen similar problems with libusb at the very beginning of mtp experimentation. If you're still interested in debugging, please check with wireshark the following scenario:

  1. Start wireshark
  2. Start qt ui or mtp-test
  3. Wait for urb reaping timeout message.
  4. Quit qt ui or mtp-test. (usb reply instantly arrived in wireshark)

Please confirm that this scenario happened for you.

whoozle commented 9 years ago

Also fixed important issue with string serialization. (missing zero byte from null termination character)

trufanov-nok commented 9 years ago

I think, i've managed to use wireshark under kubuntu. There are 3 captures in this file 1 launch: I got timeout reaping usb urb. GUI didn't open. 2 launch: I got vector::_M_range_check:__n (which is 0) >= this->size() (which is 0). GUI opened but empty. 3 launch: GUI started and displayed correct content.

first 4 packets in each capture seems to be some ping generated by wireshark itself.

whoozle commented 9 years ago

Thank you. But this file could not be opened on my system, looks like it was not fully uploaded or something. This is second time I see your damaged files, maybe you have some system problems, like corrupted filesystem or unstable memory performance?

trufanov-nok commented 9 years ago

I'm able to download and open it with Ark. I've uploaded uncompressed files here: http://1drv.ms/1K4cr3E

trufanov-nok commented 9 years ago

Was you able to download uncompressed files?

whoozle commented 9 years ago

Yes, I was, but they shows me exact the behavior I described above. Looks like your device actually sends reply to the command but kernel does not receive it (or does not set something on a bus, dunno). I need help from someone with deep knowledge of linux usb stack. :)

trufanov-nok commented 9 years ago

I have played with debugger and found that vector::_M_range_check:__n (which is 0) >= this->size() (which is 0) error happens in GetDeviceInfoImpl() at gdi.Read(stream); bcs stream is empty. Read() gets 03 00 01 20 00 00 00 00 which seems to be OK response with empty data.

trufanov-nok commented 9 years ago

And if you call _packeter.Read(0, data, code, response); one more time in this case - the app work as expected.

But this problem happens only after problem No.1: timeout reaping usb urb. So perhaps if we'll manage to solve it the second problem disappear at all.

trufanov-nok commented 9 years ago

And as for problem No.1 - I have a strong feeling that calling libusb_reset_device and reopening a session will fix it. As you know, I experience a predictable sequence of problems: No.1, No.2 and everything fine after that. So I can expect which problem should happen this time. Once just before probem No.1 I launched mtp-detect. It's output was:

Listing raw device(s)
Device 0 (VID=0421 and PID=0661) is a Nokia Nokia Lumia WP8.
   Found 1 device(s):
   Nokia: Nokia Lumia WP8 (0421:0661) @ bus 1, dev 10
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
object 1 has parent 0xffffffff (-1) continuing anyway
object c has parent 0xffffffff (-1) continuing anyway
object 10 has parent 0xffffffff (-1) continuing anyway
object 403 has parent 0xffffffff (-1) continuing anyway
object 9ff has parent 0xffffffff (-1) continuing anyway
object a00 has parent 0xffffffff (-1) continuing anyway
USB low-level info:
   bcdUSB: 512
...

And then I launched your app. Instead of problem No.1 (as expected) the app started to work normally. So calling libusb_reset_device and reopening a session should solve WP problems. Could you make a branch with libusb as backed that resets device and reopens session in case read timeout happens in Device::OpenSession? I could test it.

whoozle commented 9 years ago

linux documentation states that it might be dangerous:

Warning

Avoid using this request. It should probably be removed. Using it typically means the device and driver will lose toggle synchronization. If you really lost synchronization, you likely need to completely handshake with the device, using a request like CLEAR_HALT or SET_INTERFACE.

http://www.hep.by/gnu/kernel/usb/usbfs-ioctl.html

Could you send me the backtrace (bt) while catching this exception?

Also you could always switch on libusb backend in CMakeCache.txt (var USB_BACKEND_LIBUSB:BOOL=ON) or pass -D option to cmake.

whoozle commented 9 years ago

At least I could fix packetizer to skip responses without data.

trufanov-nok commented 9 years ago

Could you send me the backtrace (bt) while catching this exception?

If you mean 2nd problem then backtrace seems to be:

8068bt
>&"bt\n"
>~"#0  0x00007ffff5da0267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55\n"
>~"#1  0x00007ffff5da1eca in __GI_abort () at abort.c:89\n"
>~"#2  0x00007ffff63ac06d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#3  0x00007ffff63a9ee6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#4  0x00007ffff63a9f31 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#5  0x00007ffff63aa199 in __cxa_rethrow () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#6  0x0000000000493e49 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<mtp::Device, std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (this=0x7fffffffd8a8, __a=...) at /usr/include/c++/4.9/bits/shared_ptr_base.h:626\n"
>~"#7  0x00000000004936a6 in std::__shared_ptr<mtp::Device, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (this=0x7fffffffd8a0, __tag=..., __a=...) at /usr/include/c++/4.9/bits/shared_ptr_base.h:1090\n"
>~"#8  0x0000000000492b5c in std::shared_ptr<mtp::Device>::shared_ptr<std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (this=0x7fffffffd8a0, __tag=..., __a=...) at /usr/include/c++/4.9/bits/shared_ptr.h:316\n"
>~"#9  0x0000000000492159 in std::allocate_shared<mtp::Device, std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (__a=...) at /usr/include/c++/4.9/bits/shared_ptr.h:588\n"
>~"#10 0x00000000004915d1 in std::make_shared<mtp::Device, std::shared_ptr<mtp::usb::BulkPipe>&> () at /usr/include/c++/4.9/bits/shared_ptr.h:604\n"
>~"#11 0x000000000048f9c8 in mtp::Device::Find () at ../mtp/ptp/Device.cpp:96\n"
>~"#12 0x000000000047866a in MainWindow::showEvent (this=0x7fffffffe300) at ../../qt/mainwindow.cpp:61\n"
>~"#13 0x00007ffff76eb141 in QWidget::event(QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#14 0x00007ffff780880b in QMainWindow::event(QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#15 0x00007ffff76af2b4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#16 0x00007ffff76b2c86 in QApplication::notify(QObject*, QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#17 0x00007ffff6930e24 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Core.so.5\n"
>~"#18 0x00007ffff76f0544 in QWidgetPrivate::show_helper() () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#19 0x00007ffff76f09b5 in QWidget::setVisible(bool) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#20 0x0000000000477d3c in main (argc=1, argv=0x7fffffffe468) at ../../qt/main.cpp:52\n"
>8068^done

I've removed QApplication::notify() to disable exceptions suppression. Console:

terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
trufanov-nok commented 9 years ago

linux documentation states that it might be dangerous:

I don't think they use USBDEVFS_RESETEP Looks like libusb_reset_device for linux is op_reset_device and they use USBDEVFS_RELEASEINTERFACE and then IOCTL_USBFS_RESET + IOCTL_USBFS_DISCONNECT_CLAIM. Perhaps these are safer?

whoozle commented 9 years ago

I think there will be drawbacks, like re-initialization all usb device stack, timeouts, reinitialization of interfaces. I tried doing reset via libusb, it freezes usb devices until I plugged out usb cable, so I don't think it will work easily. Anyway, I removed any non-session requests except OpenSession, so no data request will be needed on startup. Please pull & test.

trufanov-nok commented 9 years ago

The problem # 2 seems to be workarounded:

$ ./qt/android-file-transfer 
upload worker started 
Object::connect: No such signal FileUploaderWorker::progress(qlonglong)
device found, opening session... 
3003 ms since the last poll call
exception timeout reaping usb urb: discard = 0
timed out getting device info:  timeout reaping usb urb , retrying... 
reaping unknown urb, usb bus conflict: 0x7fffd9e369d0 0x7fffd9e368b0
terminate called without an active exception
Аварийный останов (сделан дамп памяти)

$ ./qt/android-file-transfer 
upload worker started 
Object::connect: No such signal FileUploaderWorker::progress(qlonglong)
device found, opening session... 
drop message 0003 201e, transaction 00000000, expected: 00000001
drop message 0003 201e, transaction 00000000, expected: 00000001
device info "NOKIA"   "909" 
session opened, starting 
whoozle commented 9 years ago

I see, this might be race in kernel. Here's my thoughts on what happened:

First launch:

  1. AFT opened session, got session already opened, but for some reason, this urb was not sent to userspace and timed out.
  2. Send another urb with OpenSession request, and got previously discarded urb, failed with std::terminate (old urb was on stack, so it was corrupted)

Second launch:

  1. you got two replies and ignore them, because they have invalid transaction, and device info is in message with transaction now.

I will try to store urbs in heap, to avoid stack corruption from kernel

trufanov-nok commented 9 years ago

Ok, please let me know when i could pull and retest.

whoozle commented 9 years ago

I store urbs in map, so the could be reaped after discarding, please test. :)

trufanov-nok commented 9 years ago

Unfortunately, now I can't connect to device at all..

$ ./qt/android-file-transfer 
upload worker started 
device found, opening session... 
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info:  timeout reaping usb urb , retrying... 
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info:  timeout reaping usb urb , retrying... 
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info:  timeout reaping usb urb , retrying... 
Ошибка сегментирования (сделан дамп памяти)

between last "retrying" and segfault i'm getting "MTP device does not respond" messagebox and able to see empty GUI. segfault happens when i'm closing GUI.

trufanov-nok commented 9 years ago

Output with hex dump http://pastebin.com/nwBrtDWd

whoozle commented 9 years ago

well, we've got some sort of stability here. :)

whoozle commented 9 years ago

Well, basically I changed almost nothing, except that old reaped urbs cannot be recognized as replies, so all expired urbs are really skipped. I think this is the difference. So, I see that first transaction was read. So, could you comment out line throw TimeoutException("timeout reaping usb urb");, Device.cpp:152 and see if something changed for you. (this will call USBDEVFS_REAPURBNDELAY regardless of poll state).

trufanov-nok commented 9 years ago

That helped. Now first launch cause "Ресурс временно недоступен" massage and empty GUI. But second launch immediately after it works perfectly. Console:

$ ./qt/android-file-transfer 
upload worker started 
device found, opening session... 
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00 
3003 ms since the last poll call
error while submitting urb: ioctl: Ресурс временно недоступен
Ошибка сегментирования (сделан дамп памяти)

$ ./qt/android-file-transfer 
upload worker started 
device found, opening session... 
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 00 00 00 00 
write:
00000000: 0c 00 00 00 01 00 01 10 01 00 00 00 
read:
00000000: 0c 00 00 00 03 00 1e 20 00 00 00 00 
drop message 0003 201e, transaction 00000000, expected: 00000001
read:
00000000: ed 01 00 00 02 00 01 10 01 00 00 00 64 00 06 00 
00000010: 00 00 64 00 51 6d 00 69 00 63 00 72 00 6f 00 73 
00000020: 00 6f 00 66 00 74 00 2e 00 63 00 6f 00 6d 00 3a 
00000030: 00 20 00 31 00 2e 00 30 00 3b 00 20 00 6d 00 69 
00000040: 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 2e 
00000050: 00 63 00 6f 00 6d 00 2f 00 44 00 65 00 76 00 69 
00000060: 00 63 00 65 00 53 00 65 00 72 00 76 00 69 00 63 
00000070: 00 65 00 73 00 3a 00 31 00 2e 00 30 00 3b 00 20 
00000080: 00 6d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 
00000090: 00 74 00 2f 00 57 00 69 00 6e 00 64 00 6f 00 77 
000000a0: 00 73 00 50 00 68 00 6f 00 6e 00 65 00 3a 00 31 
000000b0: 00 2e 00 30 00 00 00 00 00 2f 00 00 00 01 10 02 
000000c0: 10 03 10 04 10 05 10 06 10 07 10 08 10 09 10 0b 
000000d0: 10 0c 10 12 10 0d 10 14 10 15 10 16 10 1a 10 1b 
000000e0: 10 17 92 34 92 01 93 02 93 03 93 04 93 05 93 0a 
000000f0: 93 01 94 02 94 03 94 04 94 05 94 10 94 11 94 12 
00000100: 94 13 94 14 94 15 94 01 98 02 98 03 98 04 98 05 
00000110: 98 06 98 08 98 10 98 11 98 20 98 06 00 00 00 04 
00000120: 40 05 40 01 c3 03 c3 04 c3 01 c8 07 00 00 00 01 
00000130: 50 02 d3 03 d3 01 d4 02 d4 05 d4 07 d4 00 00 00 
00000140: 00 1a 00 00 00 00 30 01 30 04 30 09 30 0a 30 01 
00000150: 38 01 b9 03 b9 81 b9 03 ba 05 ba 0b ba 07 38 08 
00000160: 38 0b 38 0d 38 04 38 04 b8 82 b9 15 b2 16 b2 84 
00000170: b9 85 b9 83 ba 85 ba 86 ba 06 4e 00 4f 00 4b 00 
00000180: 49 00 41 00 00 00 04 39 00 30 00 39 00 00 00 0d 
00000190: 38 00 2e 00 31 00 30 00 2e 00 31 00 34 00 32 00 
000001a0: 32 00 36 00 2e 00 30 00 00 00 21 36 00 35 00 62 
000001b0: 00 36 00 65 00 61 00 33 00 65 00 33 00 38 00 30 
000001c0: 00 64 00 37 00 64 00 64 00 62 00 33 00 36 00 31 
000001d0: 00 39 00 65 00 32 00 63 00 62 00 39 00 36 00 34 
000001e0: 00 30 00 39 00 31 00 34 00 66 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 01 00 00 00 
device info "NOKIA"   "909" 
write:
00000000: 18 00 00 00 01 00 07 10 02 00 00 00 ff ff ff ff 
00000010: 00 00 00 00 ff ff ff ff 
read:
00000000: 28 00 00 00 02 00 07 10 02 00 00 00 06 00 00 00 
00000010: 01 00 00 00 0c 00 00 00 10 00 00 00 03 04 00 00 
00000020: ff 09 00 00 00 0a 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 02 00 00 00 
session opened, starting 
write:
00000000: 10 00 00 00 01 00 08 10 03 00 00 00 10 00 00 00 
read:
00000000: b2 00 00 00 02 00 08 10 03 00 00 00 01 00 01 00 
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 
00000040: 06 4d 00 75 00 73 00 69 00 63 00 00 00 17 32 00 
00000050: 30 00 31 00 33 00 30 00 33 00 31 00 30 00 54 00 
00000060: 31 00 36 00 34 00 35 00 35 00 37 00 2e 00 31 00 
00000070: 2b 00 30 00 34 00 30 00 30 00 00 00 17 32 00 30 
00000080: 00 31 00 35 00 30 00 34 00 32 00 31 00 54 00 31 
00000090: 00 38 00 31 00 35 00 31 00 32 00 2e 00 39 00 2b 
000000a0: 00 30 00 34 00 30 00 30 00 00 00 00 00 00 00 00 
000000b0: 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 03 00 00 00 
write:
00000000: 10 00 00 00 01 00 08 10 04 00 00 00 0c 00 00 00 
read:
00000000: ba 00 00 00 02 00 08 10 04 00 00 00 01 00 01 00 
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 
00000040: 0a 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64 
00000050: 00 73 00 00 00 17 32 00 30 00 31 00 34 00 30 00 
00000060: 38 00 31 00 36 00 54 00 30 00 31 00 35 00 37 00 
00000070: 30 00 37 00 2e 00 30 00 2b 00 30 00 34 00 30 00 
00000080: 30 00 00 00 17 32 00 30 00 31 00 35 00 30 00 34 
00000090: 00 32 00 34 00 54 00 31 00 32 00 35 00 36 00 33 
000000a0: 00 35 00 2e 00 32 00 2b 00 30 00 34 00 30 00 30 
000000b0: 00 00 00 00 00 00 00 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 04 00 00 00 
write:
00000000: 10 00 00 00 01 00 08 10 05 00 00 00 01 00 00 00 
read:
00000000: ba 00 00 00 02 00 08 10 05 00 00 00 01 00 01 00 
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 
00000040: 0a 44 00 6f 00 63 00 75 00 6d 00 65 00 6e 00 74 
00000050: 00 73 00 00 00 17 32 00 30 00 31 00 33 00 30 00 
00000060: 33 00 31 00 30 00 54 00 31 00 36 00 34 00 35 00 
00000070: 35 00 39 00 2e 00 39 00 2b 00 30 00 34 00 30 00 
00000080: 30 00 00 00 17 32 00 30 00 31 00 35 00 30 00 34 
00000090: 00 30 00 38 00 54 00 31 00 33 00 31 00 36 00 35 
000000a0: 00 33 00 2e 00 32 00 2b 00 30 00 34 00 30 00 30 
000000b0: 00 00 00 00 00 00 00 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 05 00 00 00 
write:
00000000: 10 00 00 00 01 00 08 10 06 00 00 00 00 0a 00 00 
read:
00000000: b4 00 00 00 02 00 08 10 06 00 00 00 01 00 01 00 
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 
00000040: 07 56 00 69 00 64 00 65 00 6f 00 73 00 00 00 17 
00000050: 32 00 30 00 31 00 33 00 30 00 33 00 31 00 30 00 
00000060: 54 00 31 00 36 00 34 00 35 00 35 00 37 00 2e 00 
00000070: 37 00 2b 00 30 00 34 00 30 00 30 00 00 00 17 32 
00000080: 00 30 00 31 00 35 00 30 00 31 00 31 00 33 00 54 
00000090: 00 31 00 36 00 32 00 37 00 31 00 39 00 2e 00 34 
000000a0: 00 2b 00 30 00 34 00 30 00 30 00 00 00 00 00 00 
000000b0: 00 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 06 00 00 00 
write:
00000000: 10 00 00 00 01 00 08 10 07 00 00 00 ff 09 00 00 
read:
00000000: ba 00 00 00 02 00 08 10 07 00 00 00 01 00 01 00 
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 
00000040: 0a 52 00 69 00 6e 00 67 00 74 00 6f 00 6e 00 65 
00000050: 00 73 00 00 00 17 32 00 30 00 31 00 33 00 30 00 
00000060: 33 00 31 00 30 00 54 00 31 00 36 00 34 00 36 00 
00000070: 30 00 30 00 2e 00 32 00 2b 00 30 00 34 00 30 00 
00000080: 30 00 00 00 17 32 00 30 00 31 00 33 00 30 00 33 
00000090: 00 31 00 30 00 54 00 31 00 36 00 34 00 36 00 30 
000000a0: 00 30 00 2e 00 32 00 2b 00 30 00 34 00 30 00 30 
000000b0: 00 00 00 00 00 00 00 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 07 00 00 00 
write:
00000000: 10 00 00 00 01 00 08 10 08 00 00 00 03 04 00 00 
read:
00000000: b8 00 00 00 02 00 08 10 08 00 00 00 01 00 01 00 
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 
00000040: 09 50 00 69 00 63 00 74 00 75 00 72 00 65 00 73 
00000050: 00 00 00 17 32 00 30 00 31 00 33 00 30 00 33 00 
00000060: 31 00 30 00 54 00 31 00 36 00 34 00 35 00 35 00 
00000070: 38 00 2e 00 31 00 2b 00 30 00 34 00 30 00 30 00 
00000080: 00 00 17 32 00 30 00 31 00 33 00 31 00 30 00 32 
00000090: 00 31 00 54 00 31 00 35 00 30 00 30 00 35 00 30 
000000a0: 00 2e 00 33 00 2b 00 30 00 34 00 30 00 30 00 00 
000000b0: 00 00 00 00 00 00 00 00 
read:
00000000: 0c 00 00 00 03 00 01 20 08 00 00 00 

I suspect that Kubuntu works with device just after it's plugged in. And perhaps it doesn't release it properly after that. I waited a few minutes after device was plugged - but still got this busy error message.

trufanov-nok commented 9 years ago

Launching mtp-detect to reset usb at very beginning changes nothing.

whoozle commented 9 years ago
  1. can you get me a backtrace of segmentation fault of the first run?
  2. do you get segmentation fault on every second run or just the first?
trufanov-nok commented 9 years ago

Just the first. I'm launching the app, getting error, then empty GUI appears. And only when I close empty GUI I'm getting segfault message.

whoozle commented 9 years ago

So, just for clarity, with that line commented, you could launch application as many times as you want without problems, except the first?

trufanov-nok commented 9 years ago

Device.cpp:152

whoozle commented 9 years ago

possibly fixed segmentation fault at exit, empty ui should not show anymore.

trufanov-nok commented 9 years ago

Hm, now i don't see empty GUI. App quits without segfault just after Device is not responding error message displayed. The problem is that now I can't connect to device. Console:

$ ./qt/android-file-transfer 
upload worker started 
device found, opening session... 
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00 
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info:  timeout reaping usb urb , retrying... 
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00 
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info:  timeout reaping usb urb , retrying... 
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00 
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info:  timeout reaping usb urb , retrying... 

Only twice I was able to connect when launched the app just after device was plugged in. And it was connected on 2nd of 3 attempts so it seems to be just a luck.

whoozle commented 9 years ago

can you test it on the latest master? I included proper ZLP handling, it might help your device. :)

trufanov-nok commented 9 years ago

Ok

2015-06-02 14:36 GMT+04:00 Vladimir notifications@github.com:

can you test it on the latest master? I included proper ZLP handling, it might help your device. :)

— Reply to this email directly or view it on GitHub https://github.com/whoozle/android-file-transfer-linux/issues/12#issuecomment-107912111 .

With best regards, Alexander Trufanov

trufanov-nok commented 9 years ago

Amazing, it works now.

$ ./qt/android-file-transfer 
kf5.kiconthemes: "Theme tree: (Breeze)"
upload worker started
device found, opening session...
device info "NOKIA"   "909"
switching to storage id  65537
session opened, starting

It might spend a few seconds on "device found, opening session..." during first launch but this is fine.

The only thing I would suggest is to give informative error message in case device can't be connected, bcs it's locked. In this case app's output is:

$ ./qt/android-file-transfer 
kf5.kiconthemes: "Theme tree: (Breeze)"
upload worker started
device found, opening session...
device info "NOKIA"   "909"

And message box with Get: invalid response code InvalidStorageID (0x2008) is displayed. Btw, if device screen is on at this moment it even pull out its virtual keypad suggesting user that he should unlock the device. But if device screen wasn't on then it's not clear what happened. It also could confuse bcs device could automatically lock itself after N minutes of idle mode when screen is switched off. So it would be great to provide more informative warning. But it's a minor issue. Feel free to close this issue.

I'm happy with current implementation and will recommend this project as only app able to connect to WP phones (at least my Lumia 1020 WP 8.1 Denim) via wire under Ubuntu systems.