• State Not Answered
  • Replies 3 replies
  • Subscribers 10 subscribers
  • Views 204 views
  • Users 0 members are here
Options
Related

Swift SDK is not handling invalid mesgNum and Endianness raw values

krooneywa

So the swift sdk does not seem to be usable as I keep faulting on this line:

public init(stream: InputStream) throws {

        let recordHeader: UInt8 = try stream.readNumeric();

        localMesgNum = LocalMesgNum(rawValue: recordHeader & FIT.LOCAL_MESG_NUM_MASK)!

        reserved = try stream.readNumeric()

        let architecture: UInt8 = try stream.readNumeric()

        endianness = Endianness(rawValue: architecture)!

The forcing of a rawValue doesn't seem to work... there is another part where MsgNum is also forced that is causing some issues as well.  I was debating on forking the code and fixing, but wanted to see if others were having this issue and if it is something that is known.

Kevin 

  • 0

    In a properly encoded FIT file endianness should never be a value other than 0 or 1. So that forced unwrapped should never fail in a well formed file. If that line is causing an issue then the file is corrupt, but the error might be a few bytes earlier in the file and it took few operations before erroring out.

    The local mesg number should never be anything other than 0-15. recordHeader is a byte and the LOCAL_MESG_NUM_MASK should make sure that the local mesg num is 0-15, so a forced unwrap of LocalMesgNum(rawValue:) is going to succeed even if the file is corrupt.  

    There should not be anywhere in the SDK. that a raw mesg num is forced in to the MesgNum enum type. If that was the case, no files would decode using the Swift SDK.

    Try decoding these files using the FIT CSV Tool. The tool uses the Java SDK, so it will be a second data point to determine if the file is corrupt or the Swift SDK has a bug. 
    https://developer.garmin.com/fit/fitcsvtool/ 

  • 0 in reply to Ben FIT

     Thanks Ben. Closing this out: I confirmed these files parse cleanly with the Obj-C SDK on the same bytes, so they're not corrupt — the Swift SDK's force-unwraps on LocalMesgNum(rawValue:) and Endianness(rawValue:) were the failure point.  I'm happy to take this offline... I really wanted to use your Swift SDK... but just kept encountering issue after issue (and couldn't find any support)... everything worked fine in your FIT CSV Tool and Fit File VIewer and obviously Obj-C as I'm still using it.  If you think you've fixed these issues in the last 11 months happy to try it again and see if I get some performance improvements... I also have negative number SINT32 bug I would love some help with if you or anyone else wants to take a look at it... I can repro that too.    

  • 0 in reply to krooneywa

    We had a bunch of posts get stuck in a moderation queue, this was one of them, so I apologize that it took 11 months to respond. 

    Eleven months ago the Swift SDK was still very new. The initial release was on May 5, 2025. There  have updates in the last 11 months, so the issues that you were seeing may have been addressed. 

    If you can provide an example file, we will take a look at it. Or if you want to put up a PR with a failing unit test, we will look at that too. We only publish to this repo, so we can't merge any PRs, but we can make the fixes upstream.
    https://github.com/garmin/fit-swift-sdk 

    There was an issue where the decoder could be off by a byte, which could explain what you were seeing. Endianness can only be 0 or 1. If the decoder is off by a byte and any other raw value is passed then the unwrap will fail. But that is an indication of an up stream error.

    We recently released performance updates to the decoder. Our testing shows a 5-20% decrease in the time to decode files. The Objective-C SDK is a wrapper on top of the C++ SDK, so it will probably always be faster.