OSTC3 import failure

[Dirk Hohndel]

On Thu, Oct 09, 2014 at 02:24:41PM -1000, Gaetan Bisson wrote:
> Hi,
> 
> Subsurface stubbornly fails to import my morning dive from my OSTC3. :(
> 
> I run subsurface-git (currently, version 84fdbef) which used to work
> perfectly ith that exact same dive computer.

Well, a change like this is somewhat more likely to be triggered by your
libdivecomputer version than by you Subsurface version.

Can you post the output of subsurface --version ?

> What happens now is Subsurface finds the dive computer and starts
> talking to it (the progress bar of the import dialog goes to about 25%
> or so) and then suddenly stops and says "Error parsing the samples" and
> nothing is imported. Attached is the libdivecomputer logfile.

Oddly, I had a similar error with an OSTC3 earlier this week, but that's a
known defective unit, so I didn't think much about it.

> 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.

> INFO: Read: size=538, data=00000000001C00003A000900000000000000000035000037000900000000000000000016000020001F0D0100F043000000000000000000000000000000000000000000000000300019000019000900000000000000000017000010000900000000000000000009000009000D0D0100F00000000000000000000B00000A00090000000000000000000700000A00090000000000000000000A00000B001F0D0100F04500000000000000000000000000000000000000000000000030000900000B00090000000000000000000900000900090000000000000000000B00000B000D0D0100F00000000000000000000A00000B00090000000000000000000A00000A00090000000000000000000A00000A001F0D0100F04400000000000000000000000000000000000000000000000030000B00000A00090000000000000000000900000900090000000000000000000900000A000D0D0100F00000000000000000000C00000B00090000000000000000000700000B000900000000000000000009000008001F0D0100F04300000000000000000000000000000000000000000000000030000900000900090000000000000000000A00000900090000000000000000000B000009000D0D0100F00000000000000000000900000900090000000000000000000B00000C00090000000000000000000B000009001F0D0100F0420000000000000000000000000000000000000000000000003000FDFD
> INFO: Read: size=1, data=4D
> ERROR: Buffer overflow detected! [in hw_ostc_parser.c:598 (hw_ostc_parser_samples_foreach)]

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

This is the code that triggers this (at least in my version of
libdivecomputer which is pretty close to git master plus a few of my own
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
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
pretty clear this is where the problem is.

/D