OSTC3 import failure

[Gaetan Bisson]

[2014-10-09 21:38:59 -0400] Dirk Hohndel:
> Can you post the output of subsurface --version ?

It's a fairly recent git build of libdivecomputer:

Subsurface v4.2-201-g84fdbefb58c7, built with libdivecomputer
v0.5.0-devel (5f765f91430f16932d96b3777404420aa2dd4c7c)

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

Thanks. The dive looks fine in the internal OSTC3 logbook, so it seems
unlikely that the dive computer memory is corrupted. I'm running a
stable but fairly recent firmware (version 1.50) so that could also be
the issue although I have been running it for a few weeks already with
no dive import problem until today.

Cheers.

-- 
Gaetan