thread '<unnamed>' panicked at 'Error handling connection.: HttpParse(Token)'

[byronhulcher]

Hi! Sorry I'm extremely new to Rust so I apologize in advance if this issue is not very useful, I'll try to provide as much information as I can!

I receive the following error very intermittently, maybe only 2-3 times over several dozen requests. I can't seem to trigger it with any pattern.

This repro occurred while requesting a 404-ing route from the routes example, but the first time I saw it I was requesting 127.0.0.1/hello which routes successfully, I just didn't have RUST_BACKTRACE=1 enabled so it didnt have a backtrace, it was the same HttpParse(Token) issue though.

• MacOS 10.12.6 (High Sierra)
• rustc 1.21.0 (3b72af97e 2017-10-09)
• cargo 0.22.0 (3423351a5 2017-10-06)
• Chrome Version 61.0.3163.100 (Official Build) (64-bit)

BHulcher-MBP:simple-server bhulcher$ RUST_LOG="simple_server=info,routes=info" RUST_BACKTRACE=1 cargo run --example routes
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/routes`
INFO:simple_server: Server started at http://127.0.0.1:7878
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
thread '<unnamed>' panicked at 'Error handling connection.: HttpParse(Token)', src/libcore/result.rs:906:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: <core::result::Result<T, E>>::expect
  10: simple_server::Server::listen::{{closure}}::{{closure}}
  11: <F as scoped_threadpool::FnBox>::call_box
  12: scoped_threadpool::Pool::new::{{closure}}
thread 'main' panicked at 'Thread pool worker panicked', /Users/bhulcher/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:236:12
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: scoped_threadpool::Scope::join_all
   6: <scoped_threadpool::Scope<'pool, 'scope> as core::ops::drop::Drop>::drop
   7: core::ptr::drop_in_place
   8: scoped_threadpool::Pool::scoped
   9: simple_server::Server::listen
  10: routes::main
  11: __rust_maybe_catch_panic
  12: std::rt::lang_start
  13: main

[byronhulcher]

Please let me know if there's anything else I could do or provide. Again I'm about ~2 hours into using Rust but I'm happy to do what I can.

[kardeiz]

This might be the same as my #65. It looks like a fix was merged in master a few hours ago, so maybe try updating.

[divarvel]

I still get it on master, to reproduce: telnet localhost <port> then ^C

[steveklabnik]

We've significantly changed the parsing recently; any way you could try again?

[byronhulcher]

I'll try to give it another shot later today, thanks for circling back on this!

[divarvel]

sure

[divarvel]

Okay, I couldn't reproduce the crash with telnet, running on master.
I've deployed it to Clever Cloud to see if other issues are fixed (it really didn't like our monitoring probe)

[divarvel]

Ok, on clever cloud I still have

2018-03-19T13:52:23.319Z: thread '<unnamed>' panicked at 'Error handling connection.: Io(Error { repr: Os { code: 104, message: "Connection reset by peer" } })', /checkout/src/libcore/result.rs:916:5

Since it's running in release mode, I don't have a backtrace

[steveklabnik]

Is there any way you could maybe have it log the contents of the request or something?

[divarvel]

It's caused by a zabbix probe, which opens a TCP connection and closes it right away. I don't have an easy way to reproduce it locally for now

[steveklabnik]

Okay! I'm going to tag this as "needs reproduction" for now. I can always sign up for clever cloud, I guess. But that won't be soon.

[divarvel]

Sure, it's not blocking for me anyway, I'm just here to reduce entropy in the universe. If I manage to have a local reproduction, then I'll post it with a proper stack trace.

(It may also be moved to a specific issue, as the original one is fixed)

[steveklabnik]

Okay, so given that, let's give this one a close. If you can come up with a reproduction, let's open a new issue with it specifically 👍