Open
Bug 1401131
Opened 7 years ago
Updated 2 years ago
Crash during command execution results in "Internal Server Error: Failed to decode response from marionette"
Categories
(Testing :: geckodriver, defect, P3)
Testing
geckodriver
Tracking
(Not tracked)
NEW
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
1.18 KB,
text/plain
|
Details |
Running the following Selenium test will force a crash of the parent process of Firefox. Geckdriver should better handle that situation and reporting that the application has unexpectedly quit. The current message is kinda misleading: 1505811816391 webdriver::server DEBUG <- 500 Internal Server Error {"value":{"error":"unknown error","message":"Failed to decode response from marionette","stacktrace":"stack backtrace:\n 0: 0x100cc16f4 - backtrace::backtrace::trace<closure>\n at /Volumes/data/Users/henrik/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.2/src/backtrace/mod.rs:42\n 1: 0x100cc1abf - backtrace::capture::Backtrace::new::ha878a9fab9e0d004\n at /Volumes/data/Users/henrik/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.2/src/capture.rs:64\n 2: 0x1009d5e4a - webdriver::error::{{impl}}::new<&str>\n at /Volumes/data/code/gecko/testing/webdriver/src/error.rs:235\n 3: 0x1009f0aba - geckodriver::marionette::{{impl}}::send\n at src/marionette.rs:1447\n 4: 0x1009efe0d - geckodriver::marionette::{{impl}}::send_command\n at src/marionette.rs:1418\n 5: 0x1009e14a8 - geckodriver::marionette::{{impl}}::handle_command\n at src/marionette.rs:556\n 6: 0x10097ebe8 - webdriver::server::{{impl}}::run<geckodriver::marionette::MarionetteHandler,geckodriver::marionette::GeckoExtensionRoute>\n at /Volumes/data/code/gecko/testing/webdriver/src/server.rs:66\n 7: 0x1009d6c4a - webdriver::server::start::{{closure}}<geckodriver::marionette::MarionetteHandler,geckodriver::marionette::GeckoExtensionRoute>\n at /Volumes/data/code/gecko/testing/webdriver/src/server.rs:259\n 8: 0x1008f7e4a - std::sys_common::backtrace::__rust_begin_short_backtrace<closure,()>\n at /Users/travis/build/rust-lang/rust/src/libstd/sys_common/backtrace.rs:136\n 9: 0x100907c73 - std::thread::{{impl}}::spawn::{{closure}}::{{closure}}<closure,()>\n at /Users/travis/build/rust-lang/rust/src/libstd/thread/mod.rs:364\n 10: 0x1009ca26a - std::panic::{{impl}}::call_once<(),closure>\n at /Users/travis/build/rust-lang/rust/src/libstd/panic.rs:296\n 11: 0x100908699 - std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,()>\n at /Users/travis/build/rust-lang/rust/src/libstd/panicking.rs:454\n 12: 0x100f7f98a - __rust_maybe_catch_panic\n at src/libpanic_unwind/lib.rs:98\n 13: 0x1009082ec - std::panicking::try<(),std::panic::AssertUnwindSafe<closure>>\n at /Users/travis/build/rust-lang/rust/src/libstd/panicking.rs:433\n 14: 0x1009056d5 - std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure>,()>\n at /Users/travis/build/rust-lang/rust/src/libstd/panic.rs:361\n 15: 0x10090795b - std::thread::{{impl}}::spawn::{{closure}}<closure,()>\n at /Users/travis/build/rust-lang/rust/src/libstd/thread/mod.rs:363\n 16: 0x1009673c3 - alloc::boxed::{{impl}}::call_box<(),closure>\n at /Users/travis/build/rust-lang/rust/src/liballoc/boxed.rs:648\n 17: 0x100f7be65 - std::sys::imp::thread::{{impl}}::new::thread_start\n at src/libstd/sys_common/thread.rs:21\n 18: 0x7fffce5a293a - _pthread_body\n 19: 0x7fffce5a2886 - _pthread_start"}}
Reporter | ||
Comment 1•7 years ago
|
||
Reporter | ||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Better handling of Firefox crashes seems like a really good thing to have in geckodriver.
Priority: -- → P3
Version: 57 Branch → unspecified
Updated•6 years ago
|
Comment 3•6 years ago
|
||
So instead of panicking, we want to handle this more gracefully by clearing any state and returning geckodriver to accept new connections again.
Blocks: 1489130
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•