I3status-rust: pulseaudio issue after restart, previously working

Created on 16 Jul 2019  路  5Comments  路  Source: greshake/i3status-rust

I'm not really sure what I did to cause this, but after restarting a few times I noticed the status was completely gone. When started on the CLI instead of from sway, this is what I see:

{"version": 1, "click_events": true}
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error in block 'sound': pulseaudio context state failed/terminated', src/libcore/result.rs:997:5
stack backtrace:
   0:     0x559b293fa243 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h0bdaeaaef6eb6fe0
   1:     0x559b293f5acb - std::sys_common::backtrace::_print::h63b8dfd365811ea3
   2:     0x559b293f8ef6 - std::panicking::default_hook::{{closure}}::hdc88ade51d49a3ae
   3:     0x559b293f8c89 - std::panicking::default_hook::hda47a00d876f9c63
   4:     0x559b293f95ff - std::panicking::rust_panic_with_hook::h0b463a713f45561e
   5:     0x559b293f9181 - std::panicking::continue_panic_fmt::h4f5727e29b52dd2c
   6:     0x559b293f9065 - rust_begin_unwind
   7:     0x559b29411c9c - core::panicking::panic_fmt::hdadde7e46b8453b5
   8:     0x559b291fcddd - core::result::unwrap_failed::h3775a1e4d0febae9
   9:     0x559b2928c877 - i3status_rs::blocks::sound::PulseAudioConnection::new::h25be78d2126d7318
  10:     0x559b2921945f - i3status_rs::blocks::sound::PulseAudioClient::new::{{closure}}::h42a53d7e31b40890
  11:     0x559b2921969f - i3status_rs::blocks::sound::PulseAudioClient::new::{{closure}}::h52a2768df93a04ed
  12:     0x559b2920a38b - std::sys_common::backtrace::__rust_begin_short_backtrace::hae247a2a6dbcd37a
  13:     0x559b2922356b - std::panicking::try::do_call::h746f3f0835b1ed5f
  14:     0x559b294015d9 - __rust_maybe_catch_panic
  15:     0x559b2920ee4f - core::ops::function::FnOnce::call_once{{vtable.shim}}::h491cc37d5cf4d76a
  16:     0x559b293eb30e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hacb7c6355809eede
  17:     0x559b29400c6f - std::sys::unix::thread::Thread::new::thread_start::h83ed388c362348cf
  18:     0x7fb159f695a1 - start_thread
  19:     0x7fb159e7a302 - __clone
  20:                0x0 - <unknown>

If I uncomment the sound block, everything loads as expected. I thought maybe the latest code would help, but after updating from a1d29ba to e47a83f the issue is still present.

bug

Most helpful comment

The error should only happen when the pulseaudio connection encounters a failure (I'm not sure how that can happen) or when it's been terminated (which we never initiate, so it must be the pulseaudio daemon shutting down).
If you get this error again you could try to disable the service run pulseaudio manual with verbose output: pulseaudio -vvvv, maybe this gives some clues on whats happening.

Besides that the unwrap doesn't seem right, I probably missed that after one of the refactoring steps.

All 5 comments

It seems to be crashing here: https://github.com/greshake/i3status-rust/blame/master/src/blocks/sound.rs#L249. I believe this should be using return() instead of unwrap() to propagate the error, but it's hard to know the original intent of the code.

Is it possible that your pulseaudio process has been terminated?

I've restarted the system, but I'm pretty sure I did confirm pulseaudio was running. I should have checked closer. Here's what I pulled out of journalctl:

-- Reboot --
Jul 15 10:18:32 fedora systemd[1482]: Starting Sound Service...
Jul 15 10:18:32 fedora systemd[1482]: Started Sound Service.
Jul 15 10:18:32 fedora pulseaudio[2116]: E: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Jul 16 20:15:17 fedora systemd[1482]: pulseaudio.service: Succeeded.
Jul 16 20:25:37 fedora systemd[1482]: Starting Sound Service...
Jul 16 20:25:37 fedora systemd[1482]: Started Sound Service.
Jul 16 20:25:37 fedora pulseaudio[10266]: E: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Jul 16 22:37:06 fedora systemd[1482]: Stopping Sound Service...
Jul 16 22:37:06 fedora pulseaudio[10266]: E: [alsa-sink-ALC298 Analog] alsa-sink.c: Error opening PCM device front:0: Permission denied
Jul 16 22:37:06 fedora pulseaudio[10266]: E: [alsa-source-ALC298 Analog] alsa-source.c: Error opening PCM device front:0: Permission denied
Jul 16 22:37:06 fedora systemd[1482]: pulseaudio.service: Succeeded.
Jul 16 22:37:06 fedora systemd[1482]: Stopped Sound Service.

Perhaps it was stopped, though the timestamps there make it seem like it was running when I filed the bug report.

The error should only happen when the pulseaudio connection encounters a failure (I'm not sure how that can happen) or when it's been terminated (which we never initiate, so it must be the pulseaudio daemon shutting down).
If you get this error again you could try to disable the service run pulseaudio manual with verbose output: pulseaudio -vvvv, maybe this gives some clues on whats happening.

Besides that the unwrap doesn't seem right, I probably missed that after one of the refactoring steps.

I am still getting this on master. Due to a separate issue with the ibus block, I always have to reload the bar using sway's reload config command, but this sometimes results in the status bar not showing up at all. Decided to look into it tonight and found out that this issue is the cause.

  1. Backtrace after sway is first run and ibus block throws a block error seems to indicate this unwrap is the cause: connection.mainloop.borrow_mut().run().unwrap();:
    Backtrace 1:
  21: <unknown>
  22: <unknown>
  23: pa_mainloop_dispatch
  24: pa_mainloop_iterate
  25: pa_mainloop_run
  26: libpulse_binding::mainloop::standard::Mainloop::run
             at ./.cargo/registry/src/github.com-1ecc6299db9ec823/libpulse-binding-2.5.0/src/mainloop/standard.rs:381
  27: i3status_rs::blocks::sound::PulseAudioClient::new::{{closure}}
             at src/blocks/sound.rs:366
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

  1. Backtrace after resetting the bar using sway's reload config command and then using the volume wheel (note the sound block and i3status-rs itself work fine, just throws a panic in the thread) seems to indicate that this unwrap is the cause:
               PulseState::Failed | PulseState::Terminated => Err(BlockError(
                    "sound".into(),
                    "pulseaudio context state failed/terminated".into(),
                ))
                .unwrap(),

Backtrace 2:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error in block 'sound': pulseaudio context state failed/terminated', src/libcore/result.rs:1165:5
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
  10: core::result::Result<T,E>::unwrap
             at /build/rust/src/rustc-1.39.0-src/src/libcore/result.rs:933
  11: i3status_rs::blocks::sound::PulseAudioConnection::new
             at src/blocks/sound.rs:251
  12: i3status_rs::blocks::sound::PulseAudioClient::new::{{closure}}
             at src/blocks/sound.rs:281
  13: i3status_rs::blocks::sound::PulseAudioClient::new::{{closure}}
             at src/blocks/sound.rs:305
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

For the first one mentioned above , I am not really sure where to begin as there are 17 unwrap();s used in the file.

For the second one, I just submitted #484 as it seems to at least fix it on my system, but then again I'm a noob so better if someone looked it over.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

concatime picture concatime  路  4Comments

lovesegfault picture lovesegfault  路  7Comments

kepi picture kepi  路  7Comments

boi4 picture boi4  路  3Comments

fedario picture fedario  路  7Comments