search

kennylevinsen / wldash

Wayland launcher/dashboard
https://sr.ht/~kennylevinsen/wldash
GNU General Public License v3.0
186 stars 16 forks source link

thread 'pa_reader' panicked #17

Closed Mel34 closed 5 years ago

Mel34 commented 5 years ago 
~ ▶ wldash start
~ ▶ wldash start
~ ▶ wldash start
~ ▶ wldash start
thread 'pa_reader' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:999:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
~ ▶ RUST_BACKTRACE=1 wldash start
~ ▶ RUST_BACKTRACE=1 wldash start
thread 'pa_reader' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:999:5
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: start_thread
  11: __clone
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
~ ▶ RUST_BACKTRACE=full wldash start
thread 'pa_reader' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:999:5
stack backtrace:
   0:     0x555a48535cf8 - <unknown>
   1:     0x555a48535458 - <unknown>
   2:     0x555a48534f7f - <unknown>
   3:     0x555a48546c36 - <unknown>
   4:     0x555a4855217c - <unknown>
   5:     0x555a485ce11c - <unknown>
   6:     0x555a485761a2 - <unknown>
   7:     0x555a4845a270 - <unknown>
   8:     0x555a485466ef - <unknown>
   9:     0x555a485487cc - <unknown>
  10:     0x7fb37b1f357f - start_thread
  11:     0x7fb37b1070e3 - __clone
  12:                0x0 - <unknown>
kennylevinsen commented 5 years ago

That's certainly not a very helpful stacktrace. Luckily, the thread that panicked has very little code in it, so I think I found the error: The PulseAudio widget fires up two threads to run the protocol, and reports if their connections failed over each their own channel.

If the first thread failed, I could end up dropping the second thread's status channel before it got around to writing to it, meaning the send would fail when it finally got around to reporting its status. Now I make sure that I always read both channels.

Could you try making a release build with master, and see if you can reproduce?

Mel34 commented 5 years ago

Can't reproduce anymore. Think it's fixed boss.