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

Examples crash when trying to open in Safari #68

Closed
booyaa opened this issue Oct 17, 2017 · 12 comments
Closed

Examples crash when trying to open in Safari #68

booyaa opened this issue Oct 17, 2017 · 12 comments

Comments

@booyaa
Copy link

booyaa commented Oct 17, 2017

Works fine in FireFox (including Nightly) and Chrome.

Versions:

  • OS: MacOS High Sierra
  • Safari: Version 11.0 (12604.1.38.1.7)
  • Kernel: Darwin hodor.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
  • rustc 1.21.0 (3b72af97e 2017-10-09)
  • cargo 0.22.0 (3423351a5 2017-10-06)
  • rustup 1.6.0 (a11c01e8c 2017-08-30)
 $ RUST_BACKTRACE=1 cargo run --example server
   Compiling simple-server v0.1.0 (file:///Users/booyaa/Dev/rust/clowns/simple-server)
    Finished dev [unoptimized + debuginfo] target(s) in 3.57 secs
     Running `target/debug/examples/server`
thread '<unnamed>' panicked at 'Tried to unwrap Status::Partial', /Users/booyaa/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/httparse-1.2.3/src/lib.rs:254:31
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: <httparse::Status<T>>::unwrap
   6: simple_server::parse_request
   7: simple_server::Server::handle_connection
   8: simple_server::Server::listen::{{closure}}::{{closure}}
   9: <F as scoped_threadpool::FnBox>::call_box
  10: scoped_threadpool::Pool::new::{{closure}}
thread 'main' panicked at 'Thread pool worker panicked', /Users/booyaa/.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: server::main
  11: __rust_maybe_catch_panic
  12: std::rt::lang_start
  13: main
@ashleygwilliams
Copy link
Collaborator

hey @booyaa ! thanks for filing. i just tried to reproduce this on my machine (same except i'm not on High Sierra) and could not. i'm gonna tag this with needs reproduction and see if we cant get someone else to reproduce it so we can get to fixing it!

if you happen to figure it out please follow up on this thread!

@urschrei
Copy link

urschrei commented Oct 17, 2017

Can't repro on High Sierra:

  • At commit: 66d8b4d
  • Safari Version 11.0 (13604.1.38.1.6)
  • rustc 1.21.0 (3b72af97e 2017-10-09), stable-x86_64-apple-darwin
  • System Version: macOS 10.13 (17A365)
  • Kernel Version: Darwin 17.0.0

@aaroncm
Copy link

aaroncm commented Oct 17, 2017

Can't repro here either.

  • Commit 66d8b4d
  • rustc 1.21.0 (3b72af97e 2017-10-09)
  • Safari Version 11.0 (13604.1.38.1.6)
  • Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

@mgattozzi
Copy link

It looks like @urschrei and @aaroncm are using a newer version of Safari. @booyaa maybe if you update Safari it'll solve your problem?

@lewiscowper
Copy link

Hello all,

I'm running the following versions of things, and can report no crash here. 😢

screen shot 2017-10-17 at 17 24 53

Version info
  • MacOS: High Sierra 10.13.1 Beta (17B35a)
  • Safari: 11.0.1 (13604.3.4)
  • Kernel: Darwin Kernel Version 17.2.0: Sun Oct 1 00:46:50 PDT 2017; root:xnu-4570.20.62~10/RELEASE_X86_64 x86_64
  • Rustc: 1.21.0 (3b72af97e 2017-10-09)
  • Cargo: 0.22.0 (3423351a5 2017-10-06)
  • Rustup: 1.6.0 (a11c01e8c 2017-08-30)

@mistydemeo
Copy link

I can't repro on High Sierra either.

Commit 66d8b4d
rustc 1.21.0
Safari Version 11.0 (13604.1.38.1.6)
Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

@Sadin
Copy link

Sadin commented Oct 17, 2017

Cant reproduce either.

  • rustc 1.21.0 (3b72af97e 2017-10-09)
  • Safari Version 11.0 (13604.1.38.1.6)
  • Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64

@booyaa
Copy link
Author

booyaa commented Oct 17, 2017

This is definitely looking like a fault with this Safari build (12604.1.38.1.7).

Thanks everyone!

If anyone has a suggestion how I might catch what Safari is trying to send in the request to simple_server, would greatly appreciate it.

@gmbeard
Copy link
Contributor

gmbeard commented Oct 17, 2017

@booyaa Your stack trace output gives it away. The current request handling code is a little naive and each request cannot exceed 512 bytes, including headers. If it does, then it unwrap()s a Partial content response result, which panics.

To demonstrate, you can replicate this using CURL...

curl --header "X-SOME-HEADER: gWbWykBHgObDHriErqIKRBqebBekBpHsqUJqQcDtDctkaeeFBwNelgvzigaEkUPKAfcnYGhgbzDOvGumdewDzCqOantKfsvaZuggZaTjqtUzOXHVYwsSjknsMTPyWzvzGrNdRExaSIjiehYvuSAMdOMpwakKlKxCPwYAyAlpqXpoiargAZnAVIRfUJVpBnotmQRsDtAZoFfSXyRvqGQluzWWVTOCItNSCqBPUfFQGoxoSewvuSStgDtCYfCnFCFNczEwGkLiPidmrpbQDPuIvopUbxvojuUrBfgjoTwslrnDIJGAWIMoMkOQzYdzxVaCDfSQlmHwkpdkxByhuWXmuLgAzgJvIuhAMMlXaHIMcGmymGCxsgUjUkzKwrzafCsfkSivOXIzNSmTGhdgBufQTqdlRbuDBZijZCOXmpwhKFzlaSleXzgMaEpDiEjxzPUwIOwhomPDVSzaTqEZCpivNWyfunffMNUaLdkxLudYEpSgwTOGUipJjvXbocrKbfFG" http://127.0.0.1:7878

The fact that noone seems to have this problem points to your individual browser configuration. It maybe that you've used one or more previous HTTP servers on127.0.0.1, and your cookie cache for this address contains a lot of cookies (well, enough to push the request size over 512 bytes). AFAIK, all these previous cookies (which haven't expired) will be sent to the example here. Try opening the example in Private Mode to see if that solves it.

@booyaa
Copy link
Author

booyaa commented Oct 17, 2017

Wow thanks @gmbeard switched to private and it didn't crash the server example! Time to go clear out the cookies for 127.0.0.1. Nice detective work!

@booyaa booyaa closed this as completed Oct 17, 2017
@booyaa booyaa reopened this Oct 17, 2017
@booyaa
Copy link
Author

booyaa commented Oct 17, 2017

Time to write a test to reproduce it, so I can have a go fixing it! 😄

@steveklabnik
Copy link
Owner

It maybe that you've used one or more previous HTTP servers on127.0.0.1, and your cookie cache for this address contains a lot of cookies (well, enough to push the request size over 512 bytes). AFAIK, all these previous cookies (which haven't expired) will be sent to the example here.

That is amazing! Like a lightbulb. Great job debugging!

This means this is a duplicate of #19

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

No branches or pull requests

10 participants