Error while trying to read the log about openambit

[rnorris]

I too am getting various memory corruption issues - (with an Ambit 3 MultiSport)

@centic9 - As far as I can tell this is introduced the latest commit - sha:a6fdcec0814e59b038702493000dbcde0b296974

If I simply disable the recent memory management changes in pmem20.c

//log_entry->samples[*sample_count].u.unknown.data = malloc(sample_len);
//memcpy(log_entry->samples[*sample_count].u.unknown.data, buf + offset + 2, sample_len);

Then the problem goes away.

NB1 Sometimes it crashed in malloc() above, other times in processing a periodic sample.

NB2 For me it's always outputting "Found unknown periodic sample spec type (0x28): len: 17" - it's always len 17 for me; and this sample spec is only in running logs (not Cycling ones).

NB3 I haven't worked out what's wrong the memory changes.

Edit: mistyped the C++ comment symbol

[acocauab]

Thanks for your answer! Commenting the lines was not enoght for me but moving to commit: 6c3c781cfdfdd8587f6ed2876f3db631e67bb132 work smoth!

[centic9]

Thanks for narrowing down the root-cause, I don't have an Ambit 3, so cannot fully test effect of changes on that part of the code. However it looks like to be a simple bug anyway, so I should be able to fix it.

[centic9]

Should hopefully be fixed again by 9e6663a

The reporting/handling of the unknown sample was actually completely incorrect, likely would happen on Suunto Ambit 2 or other devices as well.

Please try the latest and report here if you still see crashes for some reason.

[marguslt]

I don't have an Ambit 3, so cannot fully test effect of changes on that part of the code

@centic9 , just thinking out loud here - separating watch log transfer from parsing would enable easier testing and debugging ( saving binary logs by devs & users, later loading those directly into parser without physical access to certain watch / firmware versions ).

Actually this is what both Movescount Android app and Moveslink2 are doing - they first dump the binary log of the activity into a file and then parse it. MC Android app also keeps copy of those binlogs, Moveslink2 tends to delete those after parsing, but it's easy to block this behavior. Meaning that it would allow testing libambit parser against binlogs created by Suunto tools and compare the results against Moveslink2 SML files or Movescount app JSON files.

Though both Movescount mobile app and Moveslink2 will reach their EOL soon, I have a reason to believe that at least Moveslink2 watch sync (local log transfer and generating SML-files) stays functional.

[centic9]

Good idea and would be very useful to make testing easier, however I likely lack the time to work on something like this, but I am naturally open to receive pull requests in that regard.

[acocauab]

Work smoth for me!

Thank you! :)