Import from Suunto Cobra TC not possible

Wolfgang Uhl wolfganguhl at
Mon Feb 17 01:28:43 UTC 2014

Additional Information: i just installed subsurface (4.0.1) on Windows -
importing the dives was successful there without problems.So for me, the
problem only occurs on Linux.
On my Linux Box (3.8-4.towo-siduction-amd64), i installed this version,
using the repository:
root at ws:/# dpkg -l |grep -i subsurface
ii  subsurface                                                    4.0.2-2
                       amd64        Logbook program for scuba divers

Mit freundlichem Gruß

Wolfgang Uhl

Tel     +49 (6351) 12 77 667
Fax    +49 (6351) 12 77 669
Mobil  +49 (1577) 43 748 52
Email  wolfganguhl at <wolfganguhl at>

2014-02-15 16:38 GMT+01:00 Jef Driesen <jef at>:

> On 15-02-14 15:28, Dirk Hohndel wrote:
>> On Sat, 2014-02-15 at 08:11 +0100, Jef Driesen wrote:
>>> On 14-02-14 17:06, Wolfgang Uhl wrote:
>>>> wow, that's quick response!
>>> Answering emails is easy. Fixing the problem usually takes a bit longer
>>> :-)
>>>  Allright, i only enabled logfile, but not dump and
>>>> started the import again, please find the logfile attached.
>>> Ok, this seems to be the same problem as reported for the Suunto Zoop a
>>> few days
>>> ago. The logfile you send me shows a full dump was downloaded, and not
>>> the dives.
>>> @Dirk: I downloaded the Subsurface v4.0.2 Windows binary, and I can
>>> confirm the
>>> problem. When I start subsurface (with an empty file), go straight to
>>> the dive
>>> computer download dialog and try to download dives, subsurface will
>>> download a
>>> full memory dump instead of the dives. This is with both logfile and
>>> dumpfile
>>> disabled. (For completeness, I canceled before the download has
>>> finished, such
>>> that the download window isn't closed.)
>>> If I now check the dumpfile option, and try again, it downloads a memory
>>> dump as
>>> expected. (Again I canceled.) But if I now uncheck the dumpfile option
>>> and try
>>> one last time, the dives are starting to download.
>>> So there is definitely something wrong with the Windows binary on the
>>> website.
>>> I'm unable to reproduce this on linux (with a self compiled binary from
>>> tag v4.0.2).
>> This appears to be the difference between a debug build (where
>> apparently gcc helpfully initializes members of classes in the default
>> constructor to all 0), vs. release bulds (where it doesn't do that).
>> So whenever I try to debug this, everything looks fine. But the release
>> binary shows the problem. I haven't found documentation that confirms
>> that this is what gcc is doing, but either way, re-reading the offending
>> code immediately showed that we were indeed not correctly initializing
>> the dump and log flags.
> I guess structs in a C++ class have to be explicitly initialized in the
> constructor. With data() in the initializer list, or a memset in the body
> as you did.
> Jef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the subsurface mailing list