bitwarden_rs::db::models::cipher::Cipher::to_json: EOF while parsing a value #509

New Issue

GiteaMirror · 2025-11-07T06:39:19-06:00

GiteaMirror commented

2025-11-07 06:39:19 -06:00

Originally created by @sbocahu on GitHub (Nov 28, 2019).

Hi,

I have no clue how this could happen (but yeay, shit happens sometimes).

Bitwarden_rs version 1.9.0 on Debian 9.
~15 users using it flowlessly for 6 months
suddenly 1 of them tells me he is missing some organization shared passwords in its local synchronized vault (browser extension)

digging it:

he can connect to the web interface, but has no passwords and is not part of the org
browser extension parameters -> synchronize is broken
logs show this backtrace:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71      
   2: std::panicking::default_hook::{{closure}}  
             at src/libstd/sys_common/backtrace.rs:59      
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
   9: bitwarden_rs::db::models::cipher::Cipher::to_json
  10: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold 
  11: bitwarden_rs::api::core::ciphers::rocket_route_fn_sync

found out that this user had one cipher with sqlite3 data column empty
resolution: delete from ciphers where data='';

Originally created by @sbocahu on GitHub (Nov 28, 2019). Hi, I have no clue how this could happen (but yeay, shit happens sometimes). - Bitwarden_rs version 1.9.0 on Debian 9. - ~15 users using it flowlessly for 6 months - suddenly 1 of them tells me he is missing some organization shared passwords in its local synchronized vault (browser extension) digging it: - he can connect to the web interface, but has no passwords and is not part of the org - browser extension parameters -> synchronize is broken - logs show this backtrace: ``` thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39 1: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:71 2: std::panicking::default_hook::{{closure}} at src/libstd/sys_common/backtrace.rs:59 at src/libstd/panicking.rs:197 3: std::panicking::default_hook at src/libstd/panicking.rs:211 4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:474 5: std::panicking::continue_panic_fmt at src/libstd/panicking.rs:381 6: rust_begin_unwind at src/libstd/panicking.rs:308 7: core::panicking::panic_fmt at src/libcore/panicking.rs:85 8: core::result::unwrap_failed 9: bitwarden_rs::db::models::cipher::Cipher::to_json 10: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold 11: bitwarden_rs::api::core::ciphers::rocket_route_fn_sync ``` - found out that this user had one cipher with sqlite3 data column empty - resolution: `delete from ciphers where data='';`

GiteaMirror closed this issue

2025-11-07 06:39:19 -06:00

GiteaMirror commented

2025-11-07 06:39:20 -06:00

@dani-garcia commented on GitHub (Nov 28, 2019):

I think that was solved for 1.10 actually, you should consider updating.

If it happens again, try setting the environment variable RUST_BACKTRACE=full before launching the server to get a more detailed report.

@dani-garcia commented on GitHub (Nov 28, 2019): I think that was solved for 1.10 actually, you should consider updating. If it happens again, try setting the environment variable `RUST_BACKTRACE=full` before launching the server to get a more detailed report.

GiteaMirror commented

2025-11-07 06:39:20 -06:00

@dani-garcia commented on GitHub (May 13, 2020):

Closed due to inactivity.

@dani-garcia commented on GitHub (May 13, 2020): Closed due to inactivity.

GiteaMirror referenced this issue

2026-04-20 12:07:42 -05:00

[GH-ISSUE #509] Logout if a manager role user opens settings of an organisation #9136

GiteaMirror referenced this issue

2026-04-23 04:35:27 -05:00

[GH-ISSUE #509] Logout if a manager role user opens settings of an organisation #13113

GiteaMirror referenced this issue