starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 01:35:54 +03:00

[GH-ISSUE #891] Download icon create panic #636

New issue

Closed

opened 2026-03-03 02:01:34 +03:00 by kerem · 7 comments

kerem commented

2026-03-03 02:01:34 +03:00

Owner

Originally created by @tomamplius on GitHub (Mar 3, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/891

After migration to bitwarden_rs version 13
The service crash when i'm login bitwarden_rs

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error(Io(Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }))', src/libcore/result.rs:1188:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
[2020-03-03 18:40:20][response][INFO] GET /icons/<domain>/icon.png (icon) => 200 OK
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1025
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:193
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:471
  11: rust_begin_unwind
             at src/libstd/panicking.rs:375
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:84
  13: core::result::unwrap_failed
             at src/libcore/result.rs:1188
  14: std::sync::once::Once::call_once::{{closure}}
  15: std::sync::once::Once::call_inner
             at src/libstd/sync/once.rs:417
  16: bitwarden_rs::api::icons::get_page_with_cookies
  17: bitwarden_rs::api::icons::get_icon
  18: bitwarden_rs::api::icons::rocket_route_fn_icon
  19: <F as rocket::handler::Handler>::handle
  20: rocket::rocket::Rocket::route_and_process
  21: <rocket::rocket::Rocket as hyper::server::Handler>::handle
  22: hyper::server::Worker<H>::handle_connection
  23: hyper::server::listener::spawn_with::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'thread '<unnamed><unnamed>' panicked at '' panicked at 'Once instance has previously been poisonedOnce instance has previously been poisoned', ', src/libstd/sync/once.rssrc/libstd/sync/once.rs::396396::2121

Originally created by @tomamplius on GitHub (Mar 3, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/891 After migration to bitwarden_rs version 13 The service crash when i'm login bitwarden_rs ``` thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error(Io(Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }))', src/libcore/result.rs:1188:5 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:84 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:61 [2020-03-03 18:40:20][response][INFO] GET /icons/<domain>/icon.png (icon) => 200 OK 4: core::fmt::write at src/libcore/fmt/mod.rs:1025 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:65 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:50 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:193 9: std::panicking::default_hook at src/libstd/panicking.rs:210 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:471 11: rust_begin_unwind at src/libstd/panicking.rs:375 12: core::panicking::panic_fmt at src/libcore/panicking.rs:84 13: core::result::unwrap_failed at src/libcore/result.rs:1188 14: std::sync::once::Once::call_once::{{closure}} 15: std::sync::once::Once::call_inner at src/libstd/sync/once.rs:417 16: bitwarden_rs::api::icons::get_page_with_cookies 17: bitwarden_rs::api::icons::get_icon 18: bitwarden_rs::api::icons::rocket_route_fn_icon 19: <F as rocket::handler::Handler>::handle 20: rocket::rocket::Rocket::route_and_process 21: <rocket::rocket::Rocket as hyper::server::Handler>::handle 22: hyper::server::Worker<H>::handle_connection 23: hyper::server::listener::spawn_with::{{closure}} note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. thread 'thread '<unnamed><unnamed>' panicked at '' panicked at 'Once instance has previously been poisonedOnce instance has previously been poisoned', ', src/libstd/sync/once.rssrc/libstd/sync/once.rs::396396::2121 ```

kerem closed this issue

2026-03-03 02:01:34 +03:00

kerem commented

2026-03-03 02:01:35 +03:00

Author

Owner

@dani-garcia commented on GitHub (Mar 3, 2020):

Does this happen with a new account if you add a couple of password entries, with URL? The stackstrace doesn't contain very useful information so we'd have to know what domain name icon is making the server crash

@dani-garcia commented on GitHub (Mar 3, 2020): Does this happen with a new account if you add a couple of password entries, with URL? The stackstrace doesn't contain very useful information so we'd have to know what domain name icon is making the server crash

kerem commented

2026-03-03 02:01:36 +03:00

Author

Owner

@tomamplius commented on GitHub (Mar 3, 2020):

Sorry i have 2 url before the issue without "200 OK"

[request][INFO] GET /icons/www.ag2rlamondiale.fr/icon.png
[request][INFO] GET /icons/epargnants.interepargne.natixis.fr/icon.png

But retrieving icons can be a non-blocking error?

@tomamplius commented on GitHub (Mar 3, 2020): Sorry i have 2 url before the issue without "200 OK" [request][INFO] GET /icons/www.ag2rlamondiale.fr/icon.png [request][INFO] GET /icons/epargnants.interepargne.natixis.fr/icon.png But retrieving icons can be a non-blocking error?

kerem commented

2026-03-03 02:01:36 +03:00

Author

Owner

@tomamplius commented on GitHub (Mar 3, 2020):

After many restart, with crash whan i'm login.
I can now login without crash.

If you want, you can close the issue.

But i can help you if you want understand this issue.
I mean that icons cache was clean on my last upgrade?
It is not the first time that I encounter this problem with the same solution for icons (crash until it's work)

@tomamplius commented on GitHub (Mar 3, 2020): After many restart, with crash whan i'm login. I can now login without crash. If you want, you can close the issue. But i can help you if you want understand this issue. I mean that icons cache was clean on my last upgrade? It is not the first time that I encounter this problem with the same solution for icons (crash until it's work)

kerem commented

2026-03-03 02:01:36 +03:00

Author

Owner

@BlackDex commented on GitHub (Mar 4, 2020):

Well, i tried both urls to download the icons reported earlier. But those do not trigger an error.
I don't know if you have a lot of icons, or of you are willing to share the urls since that could be a privacy/security concern.

One way to test it, is by deleting those cached icons from the icon_cache folder one by one and reload the page. Or maybe multiple to speed it a bit up, but max 5 else it would be getting difficult.

I can try and create a small bash script which could try and automat it if you can access the icon_cache folder from a linux cli/shell.

Or maybe share the list of urls privately via the matrix chat?

@BlackDex commented on GitHub (Mar 4, 2020): Well, i tried both urls to download the icons reported earlier. But those do not trigger an error. I don't know if you have a lot of icons, or of you are willing to share the urls since that could be a privacy/security concern. One way to test it, is by deleting those cached icons from the icon_cache folder one by one and reload the page. Or maybe multiple to speed it a bit up, but max 5 else it would be getting difficult. I can try and create a small bash script which could try and automat it if you can access the icon_cache folder from a linux cli/shell. Or maybe share the list of urls privately via the matrix chat?

kerem commented

2026-03-03 02:01:36 +03:00

Author

Owner

@tomamplius commented on GitHub (Mar 5, 2020):

I have delete all file in /opt/bitwarden/data/icon_cache/
I can't reproduce
I can send you log file on Matrix @thomas:lgy.fr

@tomamplius commented on GitHub (Mar 5, 2020): I have delete all file in /opt/bitwarden/data/icon_cache/ I can't reproduce I can send you log file on Matrix @thomas:lgy.fr

kerem commented

2026-03-03 02:01:36 +03:00

Author

Owner

@BlackDex commented on GitHub (Mar 5, 2020):

@tomamplius I have contacted you via matrix :).

@BlackDex commented on GitHub (Mar 5, 2020): @tomamplius I have contacted you via matrix :).

kerem commented

2026-03-03 02:01:36 +03:00

Author

Owner

@tomamplius commented on GitHub (Mar 5, 2020):

I Can't reproduce
Close and re-open if needed

@dani-garcia Thanks a lot for your work to you and others project participant

@tomamplius commented on GitHub (Mar 5, 2020): I Can't reproduce Close and re-open if needed @dani-garcia Thanks a lot for your work to you and others project participant