Panic in path_for_latest

[jyn514]

This is coming from https://github.com/rust-lang/docs.rs/blob/master/src/web/rustdoc.rs#L312.

Somehow, there's a case where req_path has a module that's not the same as target_name, but also not a target. Maybe a renamed crate?

This is all the information I have from the logs:

backtrace

Jan 07 15:43:38 docsrs cratesfyi[417]: thread '<unnamed>' panicked at 'index out of bounds: the len is 4 but the index is 4', src/web/rustdoc.rs:312:53
Jan 07 15:43:38 docsrs cratesfyi[417]: stack backtrace:
... truncated ...
Jan 07 15:43:38 docsrs cratesfyi[417]:   14: core::panicking::panic_bounds_check
Jan 07 15:43:38 docsrs cratesfyi[417]:              at src/libcore/panicking.rs:96
Jan 07 15:43:38 docsrs cratesfyi[417]:   15: cratesfyi::web::rustdoc::rustdoc_html_server_handler
Jan 07 15:43:38 docsrs cratesfyi[417]:   16: <F as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   17: <alloc::boxed::Box<dyn iron::middleware::Handler> as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   18: <cratesfyi::web::routes::BlockBlacklistedPrefixes as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   19: <alloc::boxed::Box<dyn iron::middleware::Handler> as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   20: router::router::Router::handle_method
Jan 07 15:43:38 docsrs cratesfyi[417]:   21: <router::router::Router as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   22: iron::middleware::Chain::continue_from_handler
Jan 07 15:43:38 docsrs cratesfyi[417]:   23: <iron::middleware::Chain as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   24: <alloc::boxed::Box<dyn iron::middleware::Handler> as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   25: <cratesfyi::web::CratesfyiHandler as iron::middleware::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   26: <iron::iron::RawHandler<H> as hyper::server::Handler>::handle
Jan 07 15:43:38 docsrs cratesfyi[417]:   27: hyper::server::Worker<H>::handle_connection
Jan 07 15:43:38 docsrs cratesfyi[417]:   28: hyper::server::listener::spawn_with::{{closure}}
Jan 07 15:43:38 docsrs cratesfyi[417]: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[jyn514]

That makes sense actually ... a renamed crate that fails to build in the latest version would cause this I think. Now to find a renamed crate that fails to build ^^

[jyn514]

What I've come up with so far:

WITH ever_failed AS (
    SELECT releases.id as release_id, build_status, name, target_name
    FROM crates INNER JOIN releases ON crates.id = releases.crate_id
    WHERE name != target_name AND NOT build_status AND is_library
)
SELECT name, target_name
FROM ever_failed
-- at least 1 success and 1 failure
GROUP BY name, target_name
HAVING SUM(build_status::int) != COUNT(release_id);

[jyn514]

Well, my guess seems to be wrong. I tried FPS 0.0.1 (succeeded) and FPS 0.0.3 (failed) (renamed FPS -> fps), but there's no panic.

[jyn514]

Got it! There's a settings.html page :) The bug happens whenever the latest version failed to build but earlier builds work and you're on settings.html and you're on the default platform.