Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic when parsing message #25

Open
matt24smith opened this issue Dec 26, 2021 · 1 comment
Open

Panic when parsing message #25

matt24smith opened this issue Dec 26, 2021 · 1 comment

Comments

@matt24smith
Copy link

Hi, thanks for creating this library!

I encounter panic when trying to parse certain messages, an example of the issue is included as follows

use nmea_parser::NmeaParser;

fn parsemsg(sentence: &str) {
    let mut parser = NmeaParser::new();

    if let Ok(payload) = parser.parse_sentence(sentence) {
        println!("did not panic yet {:?}", payload);
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn this_works() {
        let sentence = "!AIVDM,1,1,,,19NS8eP01t2rTJugUtmqOoVL00R@,0*53";
        parsemsg(sentence);
        let sentence2 = "!AIVDM,not,a,valid,nmea,string,0*00";
        parsemsg(sentence2);
    }

    #[test]
    fn this_panics() {
        let sentence = "!AIVDM,1,1,,,;ie05s`0Kk6UvFiQ`IaUfW3iC8pB,0*02";
        parsemsg(sentence);
    }
}

Produces output

running 2 tests
test errcheck::tests::this_works ... ok
test errcheck::tests::this_panics ... FAILED

failures:

---- errcheck::tests::this_panics stdout ----
thread 'errcheck::tests::this_panics' panicked at 'No such local time', /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/offset/mod.rs:173:34
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/1.57.0/library/std/src/panicking.rs:543:12
   1: chrono::offset::LocalResult<T>::unwrap
             at /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/offset/mod.rs:173:34
   2: chrono::offset::TimeZone::ymd
             at /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/offset/mod.rs:214:9
   3: nmea_parser::ais::vdm_t11::handle
             at /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-parser-0.8.0/src/ais/vdm_t11.rs:31:17
   4: nmea_parser::NmeaParser::parse_sentence
             at /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-parser-0.8.0/src/lib.rs:577:31
   5: rust_aisdb_lib::errcheck::parsemsg
             at ./src/errcheck.rs:6:26
   6: rust_aisdb_lib::errcheck::tests::this_panics
             at ./src/errcheck.rs:26:9
   7: rust_aisdb_lib::errcheck::tests::this_panics::{{closure}}
             at ./src/errcheck.rs:24:5
   8: core::ops::function::FnOnce::call_once
             at /rustc/1.57.0/library/core/src/ops/function.rs:227:5
   9: core::ops::function::FnOnce::call_once
             at /rustc/1.57.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    errcheck::tests::this_panics

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 3 filtered out; finished in 0.06s

error: test failed, to rerun pass '--lib'
@matt24smith
Copy link
Author

This is a challenging issue, as far as I can tell, the code in this package is correct and the issue arises with malformed messages and dependent libraries.

The panics appear to be caused by malformed UTC date response and binary application messages - I only care about vessel data, so in my case, I can safely discard these before decoding using the following function.

/// discard UTC date response and binary application payloads before decoding them
pub fn msgfilter(msg: &str) -> Option<&str> {
    if &msg.chars().count() >= &15 && &msg[..12] == "!AIVDM,1,1,," {
        match &msg[12..13] {
            "0" | "1" | "2" | "3" | "A" | "B" => match &msg[14..15] {
                ";" | "I" | "J" => None,
                _ => Some(msg),
            },
            _ => Some(msg),
        }
    } else {
        Some(msg)
    }
}

I imagine not everybody will need the binary application messages, would it make sense to skip these by default with an option to decode?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant