Re: OSTC3 import failure

[Jef Driesen]

On 2014-10-10 03:38, Dirk Hohndel wrote:

On Thu, Oct 09, 2014 at 02:24:41PM -1000, Gaetan Bisson wrote:

If I also try to enable a dumpfile, then a popup says "Dive data import

error" and nothing is imported and no dumpfile is created.

The OSTC3 doesn't support memory dumps, IIRC.

But I already extracted the raw dive from the logfile and attached it.

The ostc3 protocol doesn't support memory dumps. As an alternative, you can run the pre-built universal app from the libdivecomputer. This has been patched to dump the raw dives to files named "dive_xxx.bin" if you run it with the -d option.

INFO: Read: size=538,

data=00000000001C00003A000900000000000000000035000037000900000000000000000016000020001F0D0100F043000000000000000000000000000000000000000000000000300019000019000900000000000000000017000010000900000000000000000009000009000D0D0100F00000000000000000000B00000A00090000000000000000000700000A00090000000000000000000A00000B001F0D0100F04500000000000000000000000000000000000000000000000030000900000B00090000000000000000000900000900090000000000000000000B00000B000D0D0100F00000000000000000000A00000B00090000000000000000000A00000A00090000000000000000000A00000A001F0D0100F04400000000000000000000000000000000000000000000000030000B00000A00090000000000000000000900000900090000000000000000000900000A000D0D0100F00000000000000000000C00000B00090000000000000000000700000B000900000000000000000009000008001F0D0100F04300000000000000000000000000000000000000000000000030000900000900090000000000000000000A00000900090000000000000000000B000009000D0D0100F00000000000000000000900000900090000000000000000000B00000C00090000000000000
000000B000009001F0D0100F0420000000000000000000000000000000000000000000000003000FDFD

INFO: Read: size=1, data=4D

ERROR: Buffer overflow detected! [in hw_ostc_parser.c:598 (hw_ostc_parser_samples_foreach)]

the culprit...

Now I may be overly suspicious, but I think this pretty much points us at

Indeed.

This is the code that triggers this (at least in my version of

patches that haven't made it into libdivecomputer, yet, but those are
unrelated to the OSTC)

               // Extended sample info.
                for (unsigned int i = 0; i < nconfig; ++i) {
                        if (info[i].divisor && (nsamples %
info[i].divisor) == 0) {
                                if (length < info[i].size) {
                                        ERROR (abstract->context,
"Buffer overflow detected!");
                                        return DC_STATUS_DATAFORMAT;
                                }

So it looks like the last read (which returned 1 byte) was expected to

pretty clear this is where the problem is.

libdivecomputer which is pretty close to git master plus a few of my own deliver a lot more data. I haven't gone through the data stream to analyze what exactly the OSTC3 was sending that confused libdivecomputer, but it's

info[3].type = 3
info[3].divisor = 2
info[3].size = 9



Jef

It seems the data was downloaded correctly. I don't think it's truncated, because the end marker 0xFDFD is there. That 1 byte read which returns 0x4D is the ready byte. That's perfectly normal. What happens during the parsing is that you have extended sample info 3 set as follows: This corresponds to ppO2 sensor data. At the point where the parsing fails (10th sample at offset 0x160), the remaining length is only 8 bytes. So that's not enough for the 9 byte large ppO2 sensor data. Now we only need to figure out the root of the problem :-)

ostc3.bin
Description: Binary data

_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface