Crash downloading from Cobalt 2 from Subsurface mobile

[Matt Thompson]

In looking at the FTDI info I tried downloading dives from my Cobalt 2 for
the first time using the bluetooth experimental build from a couple of days
ago. There were no new dives to be downloaded as shown in the attached log
but after checking for new dives, the app simply crashes.

This is on a OnePlus 5T running Android 8.1.

[Dirk Hohndel]

Post by Matt Thompson
In looking at the FTDI info I tried downloading dives from my Cobalt 2 for
the first time using the bluetooth experimental build from a couple of days
ago. There were no new dives to be downloaded as shown in the attached log
but after checking for new dives, the app simply crashes.

Here's the interesting part of the log:

"160.834: DCDownloadThread started for Atomic Aquatics Cobalt 2 on FTDI"
Starting download from ftdi
Starting the thread 0
"160.855: model=Cobalt 2 firmware=161218564 serial=45150833"
"160.879: Dive 1: Sun Apr 15, 2018 1:07 PM"
"160.879: Already downloaded dive at Sun Apr 15, 2018 1:07 PM"

Of course it's lying to you because it is NOT using FTDI - this is a USB
device that it just talks to directly. And it seems to successfully talk
to the Cobalt, able to download the the firmware version (that number does
look odd), serial number (also looks a bit odd), first dive and then move
on.

What I'd love to know is why it crashes... nothing in the log indicates
what's going wrong there...

/D

[Matt Thompson]

Post by Dirk Hohndel
Of course it's lying to you because it is NOT using FTDI - this is a USB

device that it just talks to directly.

Good to know. I'll stop posting about that one in FTDI threads :)

Post by Dirk Hohndel
And it seems to successfully talk
to the Cobalt, able to download the the firmware version (that number does
look odd),

Indeed. The firmware version reported on the device is 2.460/4

Post by Dirk Hohndel
serial number (also looks a bit odd),

The serial number is actually (mostly) correct. As reported on the device
it is 4515-0833 as opposed to 45150833

Post by Dirk Hohndel
first dive and then move on.
What I'd love to know is why it crashes... nothing in the log indicates
what's going wrong there...

Yup. No other information on screen or anything. Just the Android system
dialog telling me it crashed and offering to launch the app again.

[Dirk Hohndel]

Post by Matt Thompson

Post by Dirk Hohndel
Of course it's lying to you because it is NOT using FTDI - this is a USB
device that it just talks to directly.

Good to know. I'll stop posting about that one in FTDI threads :)

Not a problem - you are simply reminding me that I need to fix this in our
output :-)

Post by Matt Thompson

Post by Dirk Hohndel
And it seems to successfully talk
to the Cobalt, able to download the the firmware version (that number does
look odd),

Indeed. The firmware version reported on the device is 2.460/4

OK, so this was the firmware version, we just need to decode it :-)
161218564 is 0x99c0004 so the two words are 0x099c = 2460 and 0x0004 = 4
Bingo :-)

Post by Matt Thompson

Post by Dirk Hohndel
serial number (also looks a bit odd),

The serial number is actually (mostly) correct. As reported on the device
it is 4515-0833 as opposed to 45150833

So we are talking to your device just fine.

Post by Matt Thompson

Post by Dirk Hohndel
first dive and then move on.
What I'd love to know is why it crashes... nothing in the log indicates
what's going wrong there...

Yup. No other information on screen or anything. Just the Android system
dialog telling me it crashed and offering to launch the app again.

Do you have access to adb on a computer? If you can connect to the Cobalt,
trigger the crash, then connect to a computer and run 'adb logcat' we
should be able to see a backtrace. That might help us figure out what's
wrong.

/D

[Matt Thompson]

Post by Dirk Hohndel
Not a problem - you are simply reminding me that I need to fix this in our
output :-)
Probably would be good to modify the dive computer dialog to not show the

connection type combo box too... I mean, as long as you are in there... :D

Post by Dirk Hohndel

Post by Matt Thompson

Post by Dirk Hohndel
And it seems to successfully talk
to the Cobalt, able to download the the firmware version (that number

does

Post by Matt Thompson

Post by Dirk Hohndel
look odd),

Indeed. The firmware version reported on the device is 2.460/4

OK, so this was the firmware version, we just need to decode it :-)
161218564 is 0x99c0004 so the two words are 0x099c = 2460 and 0x0004 = 4
Bingo :-)

Post by Matt Thompson

Post by Dirk Hohndel
serial number (also looks a bit odd),

The serial number is actually (mostly) correct. As reported on the

device

Post by Matt Thompson
it is 4515-0833 as opposed to 45150833

So we are talking to your device just fine.

Post by Matt Thompson

Post by Dirk Hohndel
first dive and then move on.
What I'd love to know is why it crashes... nothing in the log indicates
what's going wrong there...

Yup. No other information on screen or anything. Just the Android system
dialog telling me it crashed and offering to launch the app again.

Do you have access to adb on a computer? If you can connect to the Cobalt,
trigger the crash, then connect to a computer and run 'adb logcat' we
should be able to see a backtrace. That might help us figure out what's
wrong.
Done. It looks like it is hitting an assert in libusb after it figures

out there is nothing to do and is trying to close the usb device.

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Dirk Hohndel
Not a problem - you are simply reminding me that I need to fix this in our
output :-)

Probably would be good to modify the dive computer dialog to not show the
connection type combo box too... I mean, as long as you are in there... :D

Not showing it is a bit awkward. Instead it now switches to "USB device"
and can't be changed. This is in the androidIntent branch.

Post by Dirk Hohndel

Post by Dirk Hohndel
Do you have access to adb on a computer? If you can connect to the Cobalt,
trigger the crash, then connect to a computer and run 'adb logcat' we
should be able to see a backtrace. That might help us figure out what's
wrong.

Done. It looks like it is hitting an assert in libusb after it figures
out there is nothing to do and is trying to close the usb device.
08-08 18:00:18.795 7181-11826/? D//data/android/subsurface/qt-models/messagehandlermodel.cpp: INFO: "19.669: Dive 1: Sun Apr 15, 2018 1:07 PM"
INFO: "19.669: Already downloaded dive at Sun Apr 15, 2018 1:07 PM"
08-08 18:00:18.796 7181-11826/? D/libusb: [ 0.044729] [00002e32] libusb: debug [libusb_release_interface] interface 0
[ 0.044806] [00002e32] libusb: debug [libusb_close]
[ 0.044833] [00002e32] libusb: debug [usbi_remove_pollfd] remove fd 74
[ 0.044869] [00002e32] libusb: debug [libusb_exit]
[ 0.044881] [00002e32] libusb: debug [libusb_exit] destroying default context
[ 0.044894] [00002e32] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[ 0.044905] [00002e32] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.044918] [00002e32] libusb: debug [handle_events] poll fds modified, reallocating
[ 0.044937] [00002e32] libusb: debug [handle_events] poll() 1 fds with timeout in 0ms
[ 0.044954] [00002e32] libusb: debug [handle_events] poll() returned 0
[ 0.044966] [00002e32] libusb: debug [libusb_unref_device] destroy device 2.1
[ 0.044980] [00002e32] libusb: debug [libusb_unref_device] destroy device 1.2
[ 0.044991] [00002e32] libusb: debug [libusb_unref_device] destroy device 1.1
[ 0.045003] [00002e32] libusb: debug [usbi_remove_pollfd] remove fd 67
08-08 18:00:18.796 7181-11826/? A/libc: ../../libusb/libusb/os/linux_usbfs.c:500: op_exit: assertion "init_count != 0" failed
08-08 18:00:18.797 7181-11826/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 11826 (QtThread), pid 7181 (edivelog.mobile)

OK, I think I understand why this crashes... now I need to figure out if
this assert just protects an action that otherwise would be invalid, or if
it really points to something catastrophic...

/D

[Dirk Hohndel]

If you don't mind being the first person to test new code that I haven't
been able to test myself...

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.152-arm.apk

This might work. Or it might get your kitten pregnant.

/D

[Dirk Hohndel]

Post by Dirk Hohndel
If you don't mind being the first person to test new code that I haven't
been able to test myself...
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.152-arm.apk

Oh, and if you do that, and it does work (not crash), can you go to the
About page, copy the full log, and send that to us?

Thanks

/D

[Matt Thompson]

Post by Dirk Hohndel

Post by Dirk Hohndel
If you don't mind being the first person to test new code that I haven't
been able to test myself...

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.152-arm.apk
Oh, and if you do that, and it does work (not crash), can you go to the
About page, copy the full log, and send that to us?
Success! Here's the log.

[Dirk Hohndel]

Post by Dirk Hohndel
Success! Here's the log.

:-)

---------- subsurface.log ----------
"30.519: UsbDevice[mName=/dev/bus/usb/001/002,mVendorId=1137,mProductId=2184,mClass=220,mSubclass=1,mProtocol=1,mManufacturerName=ATOMIC AQUATICS,mProductName=COBALT,mVersion=2.0,mSerialNumber=123456789ABCDEF,mConfigurations=[\nUsbConfiguration[mId=1,mName=Console,mAttributes=224,mMaxPower=250,mInterfaces=[\nUsbInterface[mId=0,mAlternateSetting=0,mName=null,mClass=220,mSubclass=160,mProtocol=176,mEndpoints=[\nUsbEndpoint[mAddress=129,mAttributes=2,mMaxPacketSize=64,mInterval=0]\nUsbEndpoint[mAddress=2,mAttributes=2,mMaxPacketSize=64,mInterval=0]\nUsbEndpoint[mAddress=130,mAttributes=2,mMaxPacketSize=64,mInterval=0]]]]"
"30.520: found token with mName: UsbDevice[mName=/dev/bus/usb/001/002"
"30.520: found token with mName: mName=Console"
"30.520: found token with mName: mName=null"

The current algorithm for this is braindead, ignore... but look:
mManufacturerName=ATOMIC AQUATICS,mProductName=COBALT,mVersion=2.0

So we can easily open the download page and select Atomic Aquatics Cobalt2
for you when you plug it in :-)

"42.150: DCDownloadThread started for Atomic Aquatics Cobalt 2 on USB device"
Starting download from ftdi

Hrmpf. I see why this is wrong on Android. I'll fix that before this lands
in master...

This is making me very happy.

/D

[Matt Thompson]

Post by Dirk Hohndel
So we can easily open the download page and select Atomic Aquatics Cobalt2
for you when you plug it in :-)
Subsurface launched automatically (well, I was prompted to choose which

dive log to open) when I plugged in the Cobalt. That was very cool!

Post by Dirk Hohndel
"42.150: DCDownloadThread started for Atomic Aquatics Cobalt 2 on USB device"

Post by Dirk Hohndel
Starting download from ftdi

Hrmpf. I see why this is wrong on Android. I'll fix that before this lands
in master...
This is making me very happy.
Glad I could help. Now I have to find the time to play with that pesky

i750tc. I have to admit I'm losing interest in that one since Aqualung
appears to have discontinued it.