Panic on Windows

[haydenflinner]

I think the key piece is 0 as *mut_, but not sure how that crept in there.
Input to dateparser, which from what i can tell doesn't use any unsafe so shouldn't be triggering any undefined behavior

03/22/202

  File "C:\Users\haydu\Documents\rust\wd\src\components\go_screen.rs:37", in wd::components::go_screen::GoScreen::parse_dest
    let res = dateparser::parse_with_timezone(dest, &Local).ok();
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\lib.rs:316", in dateparser::parse_with_timezone<chrono::offset::local::Local>
    Parse::new(tz, Utc::now().time()).parse(input)
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\datetime.rs:26", in dateparser::datetime::Parse<chrono::offset::local::Local>::parse<chrono::offset::local::Local>
    self.unix_timestamp(input)
  File "rust:library\core\src\option.rs:1513", in enum2$<core::option::Option<enum2$<core::result::Result<chrono::datetime::DateTime<chrono::offset::utc::Utc>,anyhow::Error> > > >::or_else<enum2$<core::result::Result<chrono::datetime::DateTime<chrono::offset::utc::Utc>,anyhow::Error> >,dateparser::dateti
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\datetime.rs:33", in dateparser::datetime::impl$0::parse::closure$6<chrono::offset::local::Local>
    .or_else(|| self.slash_mdy_family(input))
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\datetime.rs:96", in dateparser::datetime::Parse<chrono::offset::local::Local>::slash_mdy_family<chrono::offset::local::Local>
    self.slash_mdy_hms(input).or_else(|| self.slash_mdy(input))
  File "rust:library\core\src\option.rs:1513", in enum2$<core::option::Option<enum2$<core::result::Result<chrono::datetime::DateTime<chrono::offset::utc::Utc>,anyhow::Error> > > >::or_else<enum2$<core::result::Result<chrono::datetime::DateTime<chrono::offset::utc::Utc>,anyhow::Error> >,dateparser::dateti
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\datetime.rs:96", in dateparser::datetime::impl$0::slash_mdy_family::closure$0<chrono::offset::local::Local>
    self.slash_mdy_hms(input).or_else(|| self.slash_mdy(input))
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\datetime.rs:627", in dateparser::datetime::Parse<chrono::offset::local::Local>::slash_mdy<chrono::offset::local::Local>
    NaiveDate::parse_from_str(input, "%m/%d/%y")
  File "rust:library\core\src\option.rs:1413", in enum2$<core::option::Option<chrono::naive::datetime::NaiveDateTime> >::and_then<chrono::naive::datetime::NaiveDateTime,chrono::datetime::DateTime<chrono::offset::local::Local>,dateparser::datetime::impl$0::slash_mdy::closure_env$2<chrono::offset::local::L
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\dateparser-0.1.7\src\datetime.rs:631", in dateparser::datetime::impl$0::slash_mdy::closure$2<chrono::offset::local::Local>
    .and_then(|datetime| self.tz.from_local_datetime(&datetime).single())
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\chrono-0.4.22\src\offset\local\mod.rs:141", in chrono::offset::local::impl$1::from_local_datetime
    inner::naive_to_local(local, true)
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\chrono-0.4.22\src\offset\local\windows.rs:47", in chrono::offset::local::inner::naive_to_local
    true => local_tm_to_time(&tm),
  File "C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\chrono-0.4.22\src\offset\local\windows.rs:273", in chrono::offset::local::inner::local_tm_to_time
    call!(TzSpecificLocalTimeToSystemTime(0 as *mut _, &mut sys_time, &mut utc));

The application panicked (crashed).
  TzSpecificLocalTimeToSystemTime failed with: The parameter is incorrect. (os error 87)
in C:\Users\haydu\.cargo\registry\src\github.com-1ecc6299db9ec823\chrono-0.4.22\src\offset\local\windows.rs:273
thread: tokio-runtime-worker

[djc]

Is there any particular reason you're still using 0.4.22? Please see if this still happens on 0.4.26.

[pitdicker]

This should get fixed with #1017.

[djc]

This should get fixed with #1017.

How/why?

[pitdicker]

This is the same issue as in #977, #651 and #371. TzSpecificLocalTimeToSystemTime fails on years outside of 1601..30828, such as the year 202 in this issue.

The 0 as *mut_ as first parameter indicates the local timezone, but is of course fishy in rust and was fixed to use ptr::null().

With #1017 we do the conversation in chrono and no longer use TzSpecificLocalTimeToSystemTime.

[djc]

I'll prioritize reviewing #1017.

[davehorner]

I believe this issue is related to my issue #1364,.

'I think the key piece is 0 as *mut_'

The key piece of what is 0 as *mut? I don't see any code on this ticket to exercise and get a panic.

btw, review of PR #1017 results in 4 failing tests.

failures:

---- offset::local::inner::tests::verify_against_tz_specific_local_time_to_system_time stdout ----
thread 'offset::local::inner::tests::verify_against_tz_specific_local_time_to_system_time' panicked at src\offset\local\windows.rs:216:17:
assertion `left == right` failed
  left: 1975-01-01T00:30:00-05:00
 right: 1975-01-01T00:30:00-04:00

---- offset::local::tests::verify_correct_offsets stdout ----
thread 'offset::local::tests::verify_correct_offsets' panicked at src\offset\local\mod.rs:249:9:
assertion `left == right` failed
  left: -18000
 right: -14400

---- offset::local::tests::verify_correct_offsets_distant_future stdout ----
thread 'offset::local::tests::verify_correct_offsets_distant_future' panicked at src\offset\local\mod.rs:276:9:
assertion `left == right` failed
  left: -14400
 right: -18000

---- offset::local::tests::verify_correct_offsets_distant_past stdout ----
thread 'offset::local::tests::verify_correct_offsets_distant_past' panicked at src\offset\local\mod.rs:263:9:
assertion `left == right` failed
  left: -18000
 right: -14400


failures:
    offset::local::inner::tests::verify_against_tz_specific_local_time_to_system_time
    offset::local::tests::verify_correct_offsets
    offset::local::tests::verify_correct_offsets_distant_future
    offset::local::tests::verify_correct_offsets_distant_past

test result: FAILED. 175 passed; 4 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.25s

error: test failed, to rerun pass `--lib`

[pitdicker]

The key piece of what is 0 as *mut? I don't see any code on this ticket to exercise and get a panic.

Don't mind that comment, it has nothing to do with the issue. The Windows API has a limited range of years it supports, anything below ca. the year 1600 will return an error.

btw, review of PR #1017 results in 4 failing tests.

Interesting! I'll have to look if one of the countless rebases broke something. Just in case, what is your timezone?

[davehorner]

I'm EDT